We should not remove entries (so keys) from the map while we are using
the key set (a view) of that map (see JavaDoc: otherwise "results of the
iteration undefined").
Signed-off-by: Markus Rathgeb <maggu2810@gmail.com>
There is a recommended ordering for all Maven POM files.
See: https://maven.apache.org/developers/conventions/code.html
The POM files has been "fixed" by using the "sortpom-maven-plugin".
The blank lines has been kept to keep the element separation for
readability.
The plugin also fixes indentation etc.
Have a look at: https://github.com/Ekryd/sortpom/wiki
The profile has been set to "recommended_2008_06" that states:
The POM Code Convention that was chosen by Maven developers in 2008
Command that has been executed:
mvn \
com.github.ekryd.sortpom:sortpom-maven-plugin:sort \
-Dsort.keepBlankLines=true \
-Dsort.predefinedSortOrder=recommended_2008_06
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>
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>
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>
Since Java 9 (JDK-8164428) the maximum resolution from the underlying clock is used.
Instead of just milliseconds the resolution can now even be tenth of microseconds.
According to the Type JavaDocs toFullString() should return the full string representation of the type to be consumed by 'valueOf(String)'.
With the changes in this PR toFullString() may return higher resolution date time strings on newer Java versions and valueOf(value) is able to parse these.
Code depending on a certain resolution returned by toFullString() should use the format(pattern) method instead so the resolution will not change.
Fixes#667
Signed-off-by: Wouter Born <github@maindrain.net>
Improve javadoc by explaining the different defined context values.
I have added "rule", "channel", "channeltype" and "cronexpression" as those are used within the automation module.
The i18n service uses "location" as context value and expects a map to be rendered.
Signed-off-by: davidgraeff <david.graeff@web.de>
A cron trigger module is actually not that "Generic" and a useful trigger type for a lot of rules.
Therefore I suggest to remove the visibility "HIDDEN" with this PR.
I have also added a context "cronexpression" to the TEXT configuration value, so that UI's can offer a cron expression
selection widget.
(we currently have: 'time','item','script','channel','dayOfWeek','rule')
Signed-off-by: davidgraeff <david.graeff@web.de>
Remove inconsistent visibility "PUBLIC". This value is not documented (there is only HIDDEN and VISIBLE) and this is the only module type that uses PUBLIC instead of just not setting this value at all.
Signed-off-by: davidgraeff <david.graeff@web.de>
The change with unit classes parent (#617) causes it to report missing imports of tec.uom.se when using static import. Before the change this was not a problem because the parent class was SmartHomeUnits. This change adds a new parent class for all units.
Signed-off-by: Hilbrand Bouwkamp <hilbrand@h72.nl>
The classes ImperialUnits and SIUnits both extended SmartHomeUnits. But the classes are used a singletons.
Signed-off-by: Hilbrand Bouwkamp <hilbrand@h72.nl>
* handle different possible service PID types
The property value "service.pid" can use different types:
* String
* String[]
* Collection of String
Only "String" has been supported.
https://github.com/openhab/openhab-core/pull/557 adds support for
String[]
https://github.com/openhab/openhab-core/pull/559 removes the support for
String[] again and adds support for the Collection type List only.
This commit ensures that String arrays and every collection type is
supported, regardless which (valid) type is used by the OSGi framework
implementation.
Fixes: https://github.com/eclipse/smarthome/issues/6710
Signed-off-by: Markus Rathgeb <maggu2810@gmail.com>
This addresses https://github.com/eclipse/smarthome/issues/5099 by adding a command description with command options along with the state description.
Command options will give a hint to UIs about the specific commands a channel provides. Command options could be rendered as a drop down and also represent the current state or rendered as push buttons to simply send a command to the ThingHandler.
The infrstructure basically copies the StateDescription infrastructure with CommandDescriptionProviders and an `DynamicCommandDescriptionProvider` interface for bindings to hook in and provide dynamic command options.
Signed-off-by: Henning Treu <henning.treu@googlemail.com>
The ready marker logic is created to hide the real usage. The ready
marker uses an "identifier" that is not specific or limited to bundles.
Currently the bundle symbolic name is used as bundle identifier.
That "convention" needs to be known at several different places.
There should be one method that created an identifier for a bundle and
"no one" needs to care about the implementation details.
Another point is that the bundle symbolic name that has been used is
optional. It may be null e.g. for bundles that has been installed by the
synthetic bundle installer mechanism etc.
The runtime assigns a bundle ID to an installed bundle that remains the
same for the bundle (see JavaDoc). The bundle ID is present all the
time.
The implementation of the "get identifier for bundle" has been choosen
to use the BSN -- if available -- (as before) but fallback to a custom
one using also the bundle ID (to be unique).
So we can provide always a non null identifier for a bundle.
It should be easily to change the identifier creation now if there is
every any need for.
Signed-off-by: Markus Rathgeb <maggu2810@gmail.com>
If a bundle misses a BSN the bundle cannot be installed.
We should provide a method to uninstall the bundle that has been created
by the synthetic installer itself.
Signed-off-by: Markus Rathgeb <maggu2810@gmail.com>
For better differentiation between different USB devices `UsbSerialDiscoveryService` is extended to add `usb_vendor_id` and `usb_product_id` properties to every thing which represents USB device.
Also-by: YordanDZhelev <zhelev.yordan@gmail.com>
Signed-off-by: Kai Kreuzer <kai@openhab.org>
* tests: run pure JUnit tests (bugfix), add MapDB tests (migrated to JUnit)
* remove project specific JDT settings
Signed-off-by: Markus Rathgeb <maggu2810@gmail.com>
The `MapDbStorageService` calls the constructor with a `null`
classloader if there has been no one supplied.
Signed-off-by: Markus Rathgeb <maggu2810@gmail.com>
* updated license headers
* added NOTICE files
* moved about.html to NOTICE files
* changed main project license
* updated build.properties
* added files to check to prevent error about missing about.html
* removed license info on p2 feature
Signed-off-by: Kai Kreuzer <kai@openhab.org>
