As we moved away from the manifest first approach the manifests are
generated by Bnd and contain the capabilities already.
So, there is no need anymore to maintain it in the Karaf features
manually.
Signed-off-by: Markus Rathgeb <maggu2810@gmail.com>
The singleton instance of "Diagnostician" is used without
synchronization.
The singleton "Diasnostician" instance is using the singleton
"EValidator.Registry" instance (without synchronization).
In very rare high load situations there has been CME detected.
My first "solution" has been to synchronize the access of
Diagnostician's instance method by using
```java
synchronized (Diagnostician.INSTANCE) {
...
```
But after realize that EMF is using internally other singletons I tried
to find any information about EMF and thread safety.
I found this one: https://javahacks.net/2016/07/13/emf-thread-safety/
EMF models are not thread-safe by default and writing multithreaded
applications is not that simple.
The more complex our application became, the more often we got
concurrent modification exceptions and had problems with filtering and
sorting operations.
So, I assume instead of adding synchronizations to our code that is
using EMF (IIRC this has been already done on the ESH hosted code base
long time ago) we should try to execute EMF code in a safe manner.
This implementation adds a "SafeEMF" OSGi service that should be used to
execute EMF code to ensure none code of EMF (or at least the ones that
calls has been migrated to the SafeEMF usage) is accessed by separate
threads at the same time.
Related to: https://github.com/openhab/openhab-core/issues/772
Signed-off-by: Markus Rathgeb <maggu2810@gmail.com>
* add nrjavaserial without liblockdev
* use only one feature for a nrjavaserial implementation
Fixes: https://github.com/openhab/openhab-core/issues/750
Signed-off-by: Markus Rathgeb <maggu2810@gmail.com>
The member variable "compositeFactory" that holds the
"CompositeModuleHandlerFactory" instance is set in the activation method
by calling the constructor of of "CompositeModuleHandlerFactory".
This reference is destroyed and unset in the deactivate method.
There exists DS managed multiple optional references to
"ModuleHandlerFactory".
The "add" logic does not touch the "compositeFactory" variable.
The "remove" logic checks if the given service reference is a
"CompositeModuleHandlerFactory" and unsets the "compositeFactory" member
variable.
If e.g. a module handler factory is injected that also implements the
CompositeModuleHandlerFactory the CompositeModuleHandlerFactory created
by the activate method is still be used. If that specific module handler
factory is removed again, the variable "compositeFactory" is unset and
there is NO CompositeModuleHandlerFactory present anymore.
There are two options:
* The instance created in the activate method should be used as long as
no other one is injected.
* The instance created in the activate method should be used all the
time.
The whole code base does not contain another specific implementation for
CompositeModuleHandlerFactory, so there is no (at least in openHAB Core)
change that a CompositeModuleHandlerFactory is injected.
So instead of adding a non deterministic usage of "some" composite
module handler factory (which will require a fix of the "set module
handler factory method" and some others), let's drop the buggy code in
the "remove module handler factory" and use the manually created
composite module handler factory all the time.
Signed-off-by: Markus Rathgeb <maggu2810@gmail.com>
This archetype generates bindings for the new bnd based build system.
It also updates specific bundle files that need information about the new binding.
This doesn't yet include generation of test projects.
Signed-off-by: Hilbrand Bouwkamp <hilbrand@h72.nl>
There workaround for a servlet implementation lower then 3 can be removed.
After we migrated from ESH to openHAB Core we could set servlet >= 3 as a requirement.
Signed-off-by: Markus Rathgeb <maggu2810@gmail.com>
We should disable the compression regardless if servlet 3 is used or
not. It does not matter which servlet version is used, the client should
receive the messages as soon as possible without compression or
buffering.
You can identify the lost SSE feature as soon as you enable the usage of
Jetty's GzipHandler.
Signed-off-by: Markus Rathgeb <maggu2810@gmail.com>
Currently, the scripts are loaded based on the lexicographical order of
the absolute paths of the scripts. This makes it difficult to control
the load order. This change bases the load order solely on the filename,
as was originally used before
https://github.com/eclipse/smarthome/pull/3855, and preserves the
ability to use scripts with the same filename.
Signed-off-by: Scott Rushworth <openhab@5iver.com>
This fixes the following warnings on Jenkins builds:
[WARNING] Failed to getClass for org.apache.maven.plugins.source.SourceJarMojo
See also: https://issues.jenkins-ci.org/browse/JENKINS-27372
Signed-off-by: Wouter Born <github@maindrain.net>
Added ScriptModuleTypeProvider, which dynamically adds available script
languages to the ParameterOptions used in Paper UI when configuring a
ScriptAction or ScriptCondition.
Signed-off-by: Scott Rushworth <openhab@5iver.com>
* channel groups should not require static channels
* Added unit tests
Also-by: Christoph Weitkamp <github@christophweitkamp.de>
Signed-off-by: Thomas Weißschuh <thomas@t-8ch.de>
