Previously, the state values were compared only if the item state was instanceof DecimalType
which did not work for channels that had a dimension specifier, such as Type:Length. The itemState
instance was of type QuantityType<Quantity<BigDecimal>> and therefore was never compared in the rules
Signed-off-by: Sebastian Irimia <aisebastian@yahoo.com>
Fixes SAT errors/warnings in resources and tests reported by SAT 0.8.0-SNAPSHOT.
Related to openhab/static-code-analysis#363
Signed-off-by: Wouter Born <github@maindrain.net>
* Added nullness annotations to 'RuleTemplateI18nUtil'
* Added nullness annotations to 'ConfigDescriptionGroupI18nUtil'
* Moved 'ConfigDescriptionI18nUtil' into internal package
* Moved 'ConfigDescriptionGroupI18nUtil' into internal package
* Moved 'ThingTypeI18nUtil' into internal package
* Use 'ConfigI18nLocalizationService' instead of 'ConfigDescriptionI18nUtil'
* Use default labels / descriptions if application of localization is not successful
* Resolved itest.bndrun files
Signed-off-by: Christoph Weitkamp <github@christophweitkamp.de>
Adds null annotations to all registries, the interfaces they implement and a few other classes.
Also-by: Christoph Weitkamp <github@christophweitkamp.de>
Signed-off-by: Wouter Born <github@maindrain.net>
* Use !isEmpty() instead of "size() > 0" or "size() != 0"
!isEmpty() expresses the intent more clearly and is therefore preferred.
Counting the number of elements can also be an expensive operation e.g. when using linked lists.
Co-Authored-By: Christoph Weitkamp <github@christophweitkamp.de>
Signed-off-by: Wouter Born <github@maindrain.net>
isEmpty() expresses the intent more clearly and is therefore preferred.
Counting the number of elements can also be an expensive operation e.g. when using linked lists.
Signed-off-by: Wouter Born <github@maindrain.net>
Fixes wrong names identified by the following rules:
* ConstantNameCheck
* LocalFinalVariableNameCheck
* LocalVariableNameCheck
* StaticVariableNameCheck
Most mismatches identified by the MemberNameCheck have also been fixed except for those where the variables are used in events/DTOs etc which would cause issues.
Signed-off-by: Wouter Born <github@maindrain.net>
Fixes the SAT warning: First javadoc author should have "Initial contribution" contribution description.
Signed-off-by: Wouter Born <github@maindrain.net>
* Move null annotations between modifiers and variable type
* Remove redundant public modifiers from interfaces where applicable
* Remove redundant `@NonNull` annotations
Signed-off-by: Wouter Born <github@maindrain.net>
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>
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>
