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>
* 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>
This aligns the keys of the injected `ctx` HashMap with the keys used when injecting the single entries of that HashMap.
It will allow JS Scripting to provide event information in a native JS object in UI-based scripts similarly to how it's done for file-based scripts.
Signed-off-by: Florian Hotze <dev@florianhotze.com>
Fixes#4834.
Partly reverts #4107.
The caching of the add-on resource is faulty, e.g. changes to the community marketplace settings don't invalidate the cache.
As Main UI now better handles add-on store loading, caching is no more needed there.
Signed-off-by: Florian Hotze <dev@florianhotze.com>
* AbstractScriptModuleHandler: Recompile scripts on dependency change
When a script's dependency changes, it should recompile the compiled script similarly to resetting the engine for uncompiled scripts.
Fixing this behaviour fixes an issue where compiled scripts stopped working after a dependency changed.
This also simplifies the code a bit.
Signed-off-by: Florian Hotze <dev@florianhotze.com>
* [automation] Add provider script extension
This new script extension allow scripts to provide openHAB entities like Items without needing to manually handle the lifecycle of those.
First, we will only provide an itemRegistry, but this can easily be extended later.
Signed-off-by: Florian Hotze <dev@florianhotze.com>
When starting openHAB, I always get the following warning:
```
14:44:47.082 [WARN ] [tplace.internal.json.JsonAddonService] - JSON Addon Service invalid URL:
```
We should avoid this warning, I don't see a problem there, and we should not confuse users with unnecessary warnings.
Signed-off-by: Florian Hotze <dev@florianhotze.com>
This is aligns the event WS name with the SSE events endpoint.
This is a breaking change for clients that have explicitly used `/ws/event-subscriber` instead of the default `/ws`.
Signed-off-by: Florian Hotze <dev@florianhotze.com>
See discussion in https://github.com/openhab/openhab-addons/issues/17504#issuecomment-2439906483.
This adds processing of the ActionOutput annotation for Thing actions with a single return value, which allows providing a label for use in the UI.
The output name for those actions is "result", which is now the default value in the @ActionOutput annotation. If a binding overrides the default name, a warning is logged.
If a Thing action returns a Map<String, Object> but does not provide the @ActionOutputs annotation, a warning is logged.
Signed-off-by: Florian Hotze <dev@florianhotze.com>
This moves the locking mechanism added in #4402 to the inheritors of AbstractScriptModuleHandler
to synchronize execution context access as well.
This fixes the problem thathttps://github.com/openhab/openhab-addons/pull/17510 worked around by using Thread.sleep.
Signed-off-by: Florian Hotze <dev@florianhotze.com>
* ActionInputHelper: Set step site to 0 if param type decimal
This makes the UI allow any step size, i.e. entering any number of decimals.
Signed-off-by: Florian Hotze <dev@florianhotze.com>
* ActionInputHelper: Apply default values when mapping from serialised to action inputs
This has been forgotten to be implemented.
Signed-off-by: Florian Hotze <dev@florianhotze.com>
* ConfigDescriptionParameter: Change default format for datetime & Update context docs
This changes the default format for the datetime context to the ISO standard.
This context is not used by add-ons and supported by the UI, so it should be possible to change it (again after #4392.)
Also update the context docs from https://next.openhab.org/docs/developer/addons/config-xml.html#supported-contexts and the UI code.
Signed-off-by: Florian Hotze <dev@florianhotze.com>
