org.openhab.core.automation.module.script...ScriptBusEventImpl was a copy of org.openhab.core.model.script...BusEvent,
which was removed in #5122.
In #5122, a org.openhab.core.automation.module.script...BusEventImpl was added, which is already used by the org.openhab.core.model.script bundle.
I think the ScriptBusEventImpl copy of the old BusEvent class was done to avoid a dependency org.openhab.core.automation.module.script => org.openhab.core.model.script.
As we now have a BusEventImpl in the automation bundle, we can use it for the DefaultScriptScopeProvider and get rid of ScriptBusEventImpl.
Signed-off-by: Florian Hotze <dev@florianhotze.com>
Comparable to #3155.
JSR-223 automation add-ons often use the script actions from the org.openhab.core.model.script bundle.
The downside is that the actions are tied to XText or at least use some hacks to provide static access to OSGi services.
This refactors the BusEvent actions, making them available as ScriptExtension via import-preset ScriptAction.
The actions are wrapped for DSL rules, to stay backward compatible.
Signed-off-by: Florian Hotze <dev@florianhotze.com>
Optionally allow providing a source, and then append (or directly) set
the REST package and authenticated username.
Signed-off-by: Cody Cutrer <cody@cutrer.us>
* Add AbstractThingHandlerDiscoveryService constructor for tests to use a different executor
* Add JavaDocs
* Make ThingHandler type generic
Signed-off-by: Ravi Nadahar <nadahar@rediffmail.com>
* Set event source for updates and commands from bindings according to new standards
In particular, prefix the channel UID with the package (org.openhab.core.thing), and
the channel UID becomes the actor.
Extends ProfileCallback to allow profiles to explicitly specify a source, and then
uses the new delegation syntax to append the channel UID source component in that
case.
Signed-off-by: Cody Cutrer <cody@cutrer.us>
* ScriptTransformationService: Fix engine closed too early
Currently, there are two issues:
When a ScriptRecord is cleared from the cache,
the ScriptTransformationService currently closes the ScriptEngine itself, without involving the ScriptEngineManager.
If a transformation script is invoked again after it has been cleared from the scriptCache, the ScriptEngineManager::createScriptEngine call makes the ScriptEngineManager first remove the old engine from its internal "store",
which includes invoking the scriptUnloaded hook. This invocation can cause an exception because the engine is already closed (by ScriptTransformationService) and hence function/method invocations inside the engine are not possible anymore.
Ff the engine implement Compilable, it is even closed two times by ScriptTransformationService, possibly causing an exception if the ScriptEngine doesn't handle multiple close() calls gracefully.
These issues are fixed by properly notifying the ScriptEngineManager when an engine should be removed and leaving the removal handling to the ScriptEngineManager.
The issues were discovered while working on #5062.
Signed-off-by: Florian Hotze <dev@florianhotze.com>
By using the discovery thread pool to do the actual registrations in AbstractDiscoveryService, binding threads won't have to wait for the registration to complete, which can be slow.
In addition, some thread-safety fixes have been done in AbstractDiscoveryService and DiscoveryServiceRegistryImpl, both to avoid contention and to ensure isolation of mutable objects.
Signed-off-by: Ravi Nadahar <nadahar@rediffmail.com>
AddonSuggestionService has had a delayed application of configuration because it was based on a timer that refreshed it every minute. This led to various issue where "wrong decision" were made based on stale information. This addresses the root cause for why the configuration wasn't delivered in a timely manner by OSGi, and removes the scheduled configuration refresh.
For the configuration to be accessible to multiple bundles, its "location" must be "a region". This must be configured before any bundle tries to use the configuration. To do this very early, it has been attached to the Activator of the "main core bundle". It doesn't have to be there, as long as it will always run very early during startup.
Signed-off-by: Ravi Nadahar <nadahar@rediffmail.com>
Additionally, change HashSet to LinkedHashSet in classes RuleGSONParser and TemplateGSONParser
to make iteration order predictable.
Signed-off-by: Ravi Nadahar <nadahar@rediffmail.com>
dependabot[bot]andGitHub
openhab-botandGitHub
Christoph WeitkampandGitHub
Florian HotzeandGitHub
Дилян ПалаузовandGitHub
Edwin IngandGitHub
Cody CutrerandGitHub
NadaharandGitHub
Holger FriedrichandGitHub
lo92frandGitHub
Dan CunninghamandGitHub
lolodomoandGitHub
Gaël L'hopitalandGitHub