enhance and cleanup the internal timers

[querdenker2k]

What I've done:

• removed "getTimedLock" don't know what it was good for?
• remove the timer impl from JRule and put it to a new class JRuleTimerHandler -> the calls are in JRule for timers are "proxied" to the new class
• allowed unique timer, where no name must be set (easier to handle when using timers inside loops)
• cleanup up in general the timer handling
• set MDC tags and log name for timers as well
• add JRuleDebounce to add a debounce for method calls

[seaside1]

Get timed locked is used for checking if there is a timer running. I'm using it for blocking access.
For instance I have a power all off physical button, but I don't want it to be pushed multiple times (i.e my kids tend to push it 10 times in a row for fun).

I still think it's better to use completable futures as it is less overhead and also it's possible to chain the timers.

I was working on changing the timers to work better with chaining.

Instead of having:

time1= 10
createOrReplaceTimer(... time1) // Do something after 10 seconds
Launch next timer with offset
createOrReplaceTimer(time1+3) // Do something else after 13 seconds
you could chain them

createOrReplaceTimer(time).createOrReplaceAdditionalTimer(//Will be invoked when first timer finishes)

Other than that it seems good. I would like to keep the timedLock (See example 2: https://github.com/seaside1/jrule#example-2

And I would like to be able to Chain the timers.

/S

[querdenker2k]

yes ok, makes all sense.

[querdenker2k]

@seaside1 Can you please help with the current error in the pipeline. I've no dependencies touched and have no idea of the osgi stuff.

[seaside1]

I've added deps for netty let see if it works. Locally it works, but some tests still fail

[querdenker2k]

Got it. Used a netty dependency in the code where i don't want to.

[seaside1]

I'll have a look shortly

[seime]

The README file should probably be reviewed as well

[querdenker2k]

The README file should probably be reviewed as well

done

[seaside1]

I'm failing to build this locally. I get

[ERROR] Message: Unable to resolve root: missing requirement [root] osgi.identity; osgi.identity=openhab-automation-jrule; type=karaf.feature; version=3.4.0.SNAPSHOT; filter:="(&(osgi.identity=openhab-automation-jrule)(type=karaf.feature)(version>=3.4.0.SNAPSHOT))" [caused by: Unable to resolve openhab-automation-jrule/3.4.0.SNAPSHOT: missing requirement [openhab-automation-jrule/3.4.0.SNAPSHOT] osgi.identity; osgi.identity=org.openhab.automation.jrule; type=osgi.bundle; version="[3.4.0.202212142049,3.4.0.202212142049]"; resolution:=mandatory [caused by: Unable to resolve org.openhab.automation.jrule/3.4.0.202212142049: missing requirement [org.openhab.automation.jrule/3.4.0.202212142049] osgi.wiring.package; filter:="(osgi.wiring.package=com.oracle.svm.core.annotate)"]]

I think this caused by the Debounce class pulling some new dependency .

Can you guys build locally?

[seaside1]

Build is working for me now. Unclear if it was java 17 vs java 11 problem, or simply my checkout that was bad.

[seaside1]

I have been having a lot lately, give me some time and I'll test and verify against my prod. I really like what you have done in this pr.

[querdenker2k]

add some integration-tests for an easier decision and a faster merge ;)

[seime]

@querdenker2k could you rebase and resolve conflicts? I know we have too many open (large) PRs and I am trying to merge some of them.

[seaside1]

Good to see this merged. I have been sick for the past weeks and was just about done testing this.