contains + get will do its job as long as all collection access uses the
same synchronization locks and as long as every put ensures there will
never by a null value be inserted.
If the map implementation checks if a key is available, we can also get
the value already (IMHO there is no need for the overhead to first
lookup if the key is present and after that is checked, we call the get
function). It should be better to get the value and check if it differs
from null.
Signed-off-by: Markus Rathgeb <maggu2810@gmail.com>
* slf4j logging: remove not needed object array creation
* remove explicit `toString()` calls and check if debug is enabled
Signed-off-by: Markus Rathgeb <maggu2810@gmail.com>
If you would like to use the runblacklist bnd instruction in an
integration test it will not work as expected.
In my current test case it is not used at all.
This is caused because an included file overrides this instruction.
IMHO it would be better to use the "Merged Instructions" feature and use
a postfix in the included file. This way you can use the non postfixed
instruction as usual.
See: https://bnd.bndtools.org/chapters/820-instructions.html#merged-instructions
Signed-off-by: Markus Rathgeb <maggu2810@gmail.com>
* add project for publisher
* add unmodified com.eclipsesource.jaxrs.publisher sources
* modify and use modified publisher
* drop tracker usage (only for custom whitelist by fragments)
* add the new code to new classes and namespace
Also-by: Kai Kreuzer <kai@openhab.org>
Signed-off-by: Markus Rathgeb <maggu2810@gmail.com>
It should not matter if the instructions are split or not.
But if it is splitted the nullness tooling don't know that the stream
after the filter contains only non null elements.
As it should not matter and to make the tooling happy...
Signed-off-by: Markus Rathgeb <maggu2810@gmail.com>
The bnd-testing-maven-plugin that is used to run the tests already
checks for the skipTests property and do not execute any tests if
defined.
We should keep the integration tests part of the reactor also if the
tests are not executed.
Signed-off-by: Markus Rathgeb <maggu2810@gmail.com>
If a component should be activated an instance is constructed and that
object is activated.
Let's split the construction and activation logic also if constructor
injection is used.
Signed-off-by: Markus Rathgeb <maggu2810@gmail.com>
* Travis CI: check POM convention
We could use Travis CI to execute some checks in front of the normal
build.
This change adds a check if the POM files follow our POM conventions.
If something fails, it show which files violates the convention and the
command that should be executed to fix the situation.
For example if the base POM file breaks the convention:
At least one POM file breaks the convention, please use sortpom to fix the POM file(s).
modified: pom.xml
You should run the following command in the root directory of your working copy:
mvn com.github.ekryd.sortpom:sortpom-maven-plugin:sort -Dsort.keepBlankLines=true -Dsort.createBackupFile=false -Dsort.predefinedSortOrder=recommended_2008_06
* add sortpom plugin to verify phase
* do not use dependency reduced pom (use scope)
Signed-off-by: Markus Rathgeb <maggu2810@gmail.com>
The current rule registry implementation provides a configuration for
the "rule reinitialization delay". That configuration is not used by the
rule registry itself but used by the rule engine implementation.
This required the rule engine implementation to contain a special code
path that checks if the injected rule registry is an instance of that
special implementation to access that configuration parameter.
As the configuration is not used by the registry itself, it does not
make sense that it is a configuration of that component.
If the rule engine (at least this special implementation) would like to
use a configurable parameter, it should be part of that specific
component implementation.
Signed-off-by: Markus Rathgeb <maggu2810@gmail.com>
After the bump of Paho from 1.2.0 to 1.2.1 the library enables the https
hostname verification.
This breaks compatibility with current consumers.
Connections cannot be established anymore.
We disable the https hostname verification to keep the old behaviour.
We should add an API so the hostname verification can be enabled if
desired.
This also makes the version 1.2.1 the lower version limit as we need to
use the API to disable the verification internally.
Related to: https://github.com/openhab/openhab-core/issues/815
Signed-off-by: Markus Rathgeb <maggu2810@gmail.com>
The antlr generator has been downloaded by a specific download maven
plugin at build time.
Instead of calling the plugin goals it would be much simpler to add the
downloaded file to the repository (I assume it has been not possible on
the Eclipse repository before).
Another benefit would be the IDE integration as the IDE does not need to
know if the plugin needs to be executed or not...
The provided antlr generator has been taken from:
http://download.itemis.com/antlr-generator-3.2.0-patch.jar
Signed-off-by: Markus Rathgeb <maggu2810@gmail.com>
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>
The test suite for the audio servlet contains a test that will fail on
systems under heavy load (or just imperformant systems).
An audio stream should be added for 1 (streamTimeout) second.
The stream is requested and it is tested that it can be accessed.
After that the test waits until the stream is no more available (this
will be the cause after "streamTimeout").
If the "add stream" and "get request for stream" operations already
exceed the "streamTimeout" limit, the test will fail.
This can be handled in the test case itself if we check the timespan we
need to get the stream and if we know that the stream is allowed to be
non present already, we continue with the next step without failing.
Fixes: https://github.com/openhab/openhab-core/issues/799
Signed-off-by: Markus Rathgeb <maggu2810@gmail.com>
* remove tycho based pom
* remove mega old parent POM for external repos
* remove p2 repository (generation)
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>
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>
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>
* specify directories so we do not rely on the current working directory
The current working directory has been changed between Bnd 4.1.0 and
4.2.0 and we should not rely on a specific choosen one.
We should set the appropriate directories ourself.
Signed-off-by: Markus Rathgeb <maggu2810@gmail.com>
For the runtime dependencies a template from the EnRoute project has
been used. To allow further customization and usages of different Maven
scopes, we migrate the template to this repo.
Signed-off-by: Markus Rathgeb <maggu2810@gmail.com>
* 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>
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>
