JSR223: make clear two different implementations of RuleRegistry are injected

[dilyanpalauzov]

For some reason JSR223 injects two different implementations of the org.openhab.core.automation interface.

This is confirmed by the Groovy code below:

import org.openhab.core.automation.RuleRegistry

org.slf4j.Logger logger = org.slf4j.LoggerFactory.getLogger("a1")

scriptExtension.importPreset("RuleSupport")
logger.info(rules.class.toString())
logger.info(rules instanceof RuleRegistry? "true": "false") // from Default preset
logger.info(rules instanceof org.openhab.core.automation.Action ? "true" : "false")

logger.info(ruleRegistry.class.toString())
logger.info(ruleRegistry instanceof RuleRegistry ? "true" : "false") // from RuleSupport preset
logger.info(ruleRegistry instanceof org.openhab.core.automation.Action ? "true" : "false")

which prints

2024-09-04 14:11:12.512 [INFO ] [ort.loader.AbstractScriptFileWatcher] - (Re-)Loading script '/etc/openhab/automation/jsr223/t.groovy'
2024-09-04 14:11:12.551 [INFO ] [a1 ] - class org.openhab.core.automation.internal.RuleRegistryImpl
2024-09-04 14:11:12.553 [INFO ] [a1 ] - true
2024-09-04 14:11:12.555 [INFO ] [a1 ] - false
2024-09-04 14:11:12.560 [INFO ] [a1 ] - class org.openhab.core.automation.module.script.rulesupport.shared.RuleSupportRuleRegistryDelegate
2024-09-04 14:11:12.562 [INFO ] [a1 ] - true
2024-09-04 14:11:12.563 [INFO ] [a1 ] - false

I asked for the rationale on this at https://community.openhab.org/t/why-does-jsr223-provide-two-implementations-of-the-ruleregistry-interface/.

[netlify]

✅ Thanks for your pull request to the openHAB documentation! The result can be previewed at the URL below (this comment and the preview will be updated if you add more commits).

Built without sensitive environment variables

Name	Link
🔨 Latest commit	8e90786
🔍 Latest deploy log	https://app.netlify.com/sites/openhab-docs-preview/deploys/66d84169f06f0c000853cf29
😎 Deploy Preview	https://deploy-preview-2360--openhab-docs-preview.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[florian-h05]

Looking at the class comments, I think only the RuleSupportRuleRegistryDelegate should be returned:

/**
 * The {@link RuleSupportRuleRegistryDelegate} is wrapping a {@link RuleRegistry} to provide a comfortable way to add
 * rules to the RuleManager without worrying about the need to remove rules again. Nonetheless, using the addPermanent
 * method it is still possible to add rules permanently.
 *
 * @author Simon Merschjohann - Initial contribution
 */
@NonNullByDefault
public class RuleSupportRuleRegistryDelegate implements RuleRegistry {

[dilyanpalauzov]

Looking at the class comments, I think only the RuleSupportRuleRegistryDelegate should be returned:

/**
 * The {@link RuleSupportRuleRegistryDelegate} is wrapping a {@link RuleRegistry} to provide a comfortable way to add
 * rules to the RuleManager without worrying about the need to remove rules again. Nonetheless, using the addPermanent
 * method it is still possible to add rules permanently.
 *
 * @author Simon Merschjohann - Initial contribution
 */
@NonNullByDefault
public class RuleSupportRuleRegistryDelegate implements RuleRegistry {

I still do not understand why two different implementations are exposed and when should which implementation be used. In any case, the propose here change is correct.

[florian-h05]

But instead of changing the docs to „one implementation“ and „another implementation“ I think this is a good chance to think about the reasons for the two different implementations and if we want to change that.

[dilyanpalauzov]

For the moment this changeset is an improvement. I also would like to have more reasonable text, but at https://community.openhab.org/t/why-does-jsr223-provide-two-implementations-of-the-ruleregistry-interface/158131 no rationale was provided.