* Raise source level to Java 17 (except for model classes)
* Remove Nashorn script engine
* Upgrade spotless and add jvm options
See https://github.com/diffplug/spotless/issues/834
* Add suppression for findBugs false positive error
* Upgrade xtext to 2.29.0
* Adjust JNA
* Resolve itests
Signed-off-by: Jan N. Klug <github@klug.nrw>
When updating file-based script transformations used in item state-descripting a CME can occur during reload. This is fixed by using thread-safe implementation of `HashMap`.
Signed-off-by: Jan N. Klug <github@klug.nrw>
When writing tests and mocking time, it can be important that
execution_time match _exactly_ with what was sent to reschedule().
When re-calculating based on now and the expected remaining delay,
this might be off by a few milliseconds. We have the exact time
that was requested already, so might as well use it.
Signed-off-by: Cody Cutrer <cody@cutrer.us>
* log full exception information when calling JSR223 scripts
The scripts are user code, so in order to help them debug their code,
the full stack trace is very useful.
Signed-off-by: Cody Cutrer <cody@cutrer.us>
* Enhance transformation configuration
This is needed to give the users the best experience when editing transformations in UI.
Signed-off-by: Jan N. Klug <github@klug.nrw>
* Add more null annotations to automation bundles. This adds null annotations to many classes in the automation bundles and a few dimension classes.
* Further cleanup AutomationCommandExport
* Remove null from RuleStatusInfo JavaDocs. This should be clear from how the class is now annotated.
* Validate deserialized RuleStatusInfo
* Allow TriggerHandlerCallback to be triggered without providing a context
Signed-off-by: Wouter Born <github@maindrain.net>
On Java 17 there is no Nashorn scripting engine so it takes a bit longer before ScriptEngines are available.
Rules would stay uninitialized forever because the ScriptModuleTypeProvider did not notify its listeners whenever script.ScriptAction, script.ScriptCondition became available.
Signed-off-by: Wouter Born <github@maindrain.net>
Trigger information is inserted in the execution context. This information is changed to the new information each time the context is updated with the same keys. If the context of the next execution does not contain values for each key, the old key is re-used, leading e.g. to wrong event information in the context.
The solution is to re-set the individual context after each execution.
Signed-off-by: Jan N. Klug <github@klug.nrw>
As discussed in https://github.com/openhab/openhab-addons/issues/11818.
This should select `application/x-python` for Jython (instead of `application/python` currently)
and allow other script engines to advertise their MIME type:
- JRuby: `application/x-ruby`
- Groovy: `application/x-groovy`
Signed-off-by: Yannick Schaus <github@schaus.net>
* Use the mime types provided by the ScriptEngineFactory and not the underlying script engines they provide. This allows mutliple versions of script engines to co-exist, like Nashorn and GraalVM .
Signed-off-by: Dan Cunningham <dan@digitaldan.com>
Not sure if there's a good rationale behind it being read-only (maybe because it's not supposed to change after having been set) but removing it will fix https://github.com/openhab/openhab-webui/issues/1061.
Signed-off-by: Yannick Schaus <github@schaus.net>
This should fix the issue reported here:
https://community.openhab.org/t/openhab-3-0-milestone-2-discussion/107564/8
where the Nashorn script engine would be created with the
current thread's class loader, causing JS code like this:
```
var Log = Java.type("org.openhab.core.model.script.actions.Log");
Log.logError("Experiments", "This is an OH error log");
Log.logWarn("Experiments", "This is an OH warn log");
Log.logInfo("Experiments", "This is an OH info log");
Log.logDebug("Experiments", "This is an OH debug log");
```
to run fine when the rule was triggered but fail to find the Log
class when run from the REST API's `/rest/rules/{ruleUID}/runnow`,
because in that case the generic createScriptEngine implementation
would return script engines using the JAX-RS class loader as the
"app" class loader.
Note:
We also have an opportunity to restrict which classes are exposed
to the script with a ClassFilter to a specific set:
https://docs.oracle.com/javase/8/docs/jdk/api/nashorn/jdk/nashorn/api/scripting/NashornScriptEngineFactory.html#getScriptEngine-java.lang.String:A-java.lang.ClassLoader-jdk.nashorn.api.scripting.ClassFilter-
This could prove useful to mitigate code execution vulnerabilities,
as the script code is modifiable remotely.
Signed-off-by: Yannick Schaus <github@schaus.net>
These workarounds to prevent false positives can be removed now the EEAs allow for proper null analysis.
Signed-off-by: Wouter Born <github@maindrain.net>
