* Use constructor injection to simplify lifecycle
Signed-off-by: Christoph Weitkamp <github@christophweitkamp.de>
* PR extended by ItemStateConverter
Signed-off-by: Christoph Weitkamp <github@christophweitkamp.de>
* Use constructor injection to simplify lifecycle
* Added nullness annotations to PersistenceManager
* Removed declaration with null
Signed-off-by: Christoph Weitkamp <github@christophweitkamp.de>
After adding the nullness annotations to the automation stuff, we need
to fix the usage to use a correct nullness handling.
Related to: https://github.com/openhab/openhab-core/pull/910
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>
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>
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>
* 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>
Adds the following bundles required for building on Java 11 by default to the run requirements:
* org.apache.servicemix.specs.activation-api-1.1
* org.apache.servicemix.specs.annotation-api-1.3
* org.apache.servicemix.specs.jaxb-api-2.2
Signed-off-by: Wouter Born <github@maindrain.net>
Incompatible code can be used/generated when using JDK8 on the command line and JDK11 in Eclipse (or vice versa).
The explanation for this is given in https://github.com/apache/felix/pull/114 :
Java 9 introduces overridden methods with covariant return types for the following methods in java.nio.ByteBuffer:
* position(int newPosition)
* limit(int newLimit)
* flip()
* clear()
* mark()
* reset()
* rewind()
In Java 9 they all now return ByteBuffer, whereas the methods they override return Buffer,
resulting in exceptions like this when executing on Java 8 and lower:
java.lang.NoSuchMethodError: java.nio.ByteBuffer.limit(I)Ljava/nio/ByteBuffer
This is because the generated byte code includes the static return type of the method, which is not found on Java 8 and lower because the overloaded methods with covariant return types don't exist (the issue appears even with source and target 8 or lower in compilation parameters).
The solution is to cast ByteBuffer instances to Buffer before calling the method.
Signed-off-by: Wouter Born <github@maindrain.net>
