add startup level trigger

[querdenker2k]

adds the startup level trigger. currently untested

[seaside1]

I'll try and test. But otherwise ready for review?

[querdenker2k]

Yes, so far it's ready, but untested

[seaside1]

Can you check the conflict in JRuleEngine? (Came with last merged PR)

[querdenker2k]

I have to adopt the test, but it's working.

[seaside1]

It's not building though. I get this when merging against origin main:

[19:04:52] josha@zool:~/git/jrule-pr-194-startup-level> git pull --rebase origin main
From https://github.com/seaside1/jrule
 * branch            main       -> FETCH_HEAD
Auto-merging src/main/java/org/openhab/automation/jrule/internal/engine/JRuleEngine.java
CONFLICT (content): Merge conflict in src/main/java/org/openhab/automation/jrule/internal/engine/JRuleEngine.java
Auto-merging src/main/java/org/openhab/automation/jrule/internal/module/JRuleModuleEntry.java
error: could not apply 392f8ae... add startup level trigger
hint: Resolve all conflicts manually, mark them as resolved with
hint: "git add/rm <conflicted_files>", then run "git rebase --continue".
hint: You can instead skip this commit: run "git rebase --skip".
hint: To abort and get back to the state before "git rebase", run "git rebase --abort".

++<<<<<<< HEAD
 +        Arrays.stream(method.getAnnotationsByType(JRuleWhenThingTrigger.class))
 +                .forEach(jRuleWhen -> jRuleBuilder.whenThingTrigger(
 +                        Optional.of(jRuleWhen.thing()).filter(StringUtils::isNotEmpty).filter(s -> !s.equals("*"))
 +                                .orElse(null),
 +                        Optional.of(jRuleWhen.from()).filter(s -> s != JRuleThingStatus.THING_UNKNOWN).orElse(null),
 +                        Optional.of(jRuleWhen.to()).filter(s -> s != JRuleThingStatus.THING_UNKNOWN).orElse(null)));
 +
 +        // Check if rule was actually activated, i.e. if triggers are present
 +        if (!jRuleBuilder.build()) {
++=======
+         Arrays.stream(method.getAnnotationsByType(JRuleWhenThingTrigger.class)).forEach(jRuleWhen -> {
+             JRuleThingExecutionContext context = new JRuleThingExecutionContext(jRule, logName, loggingTags, method,
+                     Optional.of(jRuleWhen.thing()).filter(StringUtils::isNotEmpty).filter(s -> !s.equals("*")),
+                     Optional.of(jRuleWhen.from()).filter(s -> s != JRuleThingStatus.THING_UNKNOWN),
+                     Optional.of(jRuleWhen.to()).filter(s -> s != JRuleThingStatus.THING_UNKNOWN),
+                     jRulePreconditionContexts, timedLock, delayed);
+             addToContext(context, enableRule);
+             ruleLoadingStatistics.addThingTrigger();
+             ruleModuleEntry.addJRuleWhenThingTrigger(context);
+             addedToContext.set(true);
+         });
+ 
+         Arrays.stream(method.getAnnotationsByType(JRuleWhenStartup.class)).forEach(jRuleWhen -> {
+             JRuleStartupExecutionContext context = new JRuleStartupExecutionContext(jRule, logName, loggingTags, method,
+                     jRulePreconditionContexts, timedLock, delayed, jRuleWhen.level());
+             addToContext(context, enableRule);
+             ruleLoadingStatistics.addStartupTrigger();
+             ruleModuleEntry.addJRuleWhenStartupTrigger(context);
+             addedToContext.set(true);
+         });
+ 
+         // Check if any rule triggers are present
+         if (!addedToContext.get()) {
++>>>>>>> 392f8ae (add startup level trigger)

[querdenker2k]

strange, I have merged main into this branch and it's up to date. And i am not able to add an integration test for this. The problem that the JRule class is loaded first and the startup level is triggered. But the JRule class is then reloaded and instantiated again without the startup level trigger.

Is this (the reloading) really useful to do sth on startup level trigger and maybe store some variables but they are all lost because the class is reinstantiated.

[seaside1]

Sorry for the mess, I was merging JRuleEngine at the same time as you @querdenker2k I think it is ok now, except its failing for some test.

Last one was a rebase against main for the mdc-test. Not sure why it fails. Locally it fails for med with the mdc tags it looks like