Looks like this workaround introduced in #2480 is unnecessary nowadays because #2484 addressed the root cause.
This fixes the AvoidCatchingThrowable SAT findings.
Signed-off-by: Wouter Born <github@maindrain.net>
* Fix StringIndexOutOfBoundsException when using rules file name that starts with 'state' (Constant Warnings in RuleMetric #2472)
* Null annotations fixes/improvements
* Add transitive com.codahale.metrics dependency which is used by io.micrometer.core.instrument.dropwizard.DropwizardMeterRegistry. This fixes a NoClassDefFoundError when implementing metrics exporters that use a MeterRegistry extending DropwizardMeterRegistry (e.g. JmxMeterRegistry).
* Prevent ConcurrentModificationException in ThreadPoolMetric at startup:
java.util.ConcurrentModificationException: null
at java.util.WeakHashMap$HashIterator.nextEntry(WeakHashMap.java:807) ~[?:?]
at java.util.WeakHashMap$KeyIterator.next(WeakHashMap.java:840) ~[?:?]
at java.lang.Iterable.forEach(Iterable.java:74) ~[?:?]
at org.openhab.core.io.monitor.internal.metrics.ThreadPoolMetric.bindTo(ThreadPoolMetric.java:55) ~[?:?]
at org.openhab.core.io.monitor.internal.DefaultMetricsRegistration.lambda$0(DefaultMetricsRegistration.java:97) ~[?:?]
at java.lang.Iterable.forEach(Iterable.java:75) ~[?:?]
at org.openhab.core.io.monitor.internal.DefaultMetricsRegistration.registerMeters(DefaultMetricsRegistration.java:97) ~[?:?]
at org.openhab.core.io.monitor.internal.DefaultMetricsRegistration.onReadyMarkerAdded(DefaultMetricsRegistration.java:115) ~[?:?]
at org.openhab.core.internal.service.ReadyServiceImpl.lambda$0(ReadyServiceImpl.java:52) ~[?:?]
at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183) ~[?:?]
at java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195) ~[?:?]
at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:177) ~[?:?]
at java.util.HashMap$EntrySpliterator.forEachRemaining(HashMap.java:1746) ~[?:?]
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484) ~[?:?]
at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474) ~[?:?]
at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150) ~[?:?]
at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173) ~[?:?]
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) ~[?:?]
at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497) ~[?:?]
at org.openhab.core.internal.service.ReadyServiceImpl.notifyTrackers(ReadyServiceImpl.java:79) ~[?:?]
at org.openhab.core.internal.service.ReadyServiceImpl.markReady(ReadyServiceImpl.java:52) ~[?:?]
at org.openhab.core.service.StartLevelService.setStartLevel(StartLevelService.java:248) ~[?:?]
at org.openhab.core.service.StartLevelService.lambda$0(StartLevelService.java:125) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) [?:?]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
at java.lang.Thread.run(Thread.java:829) [?:?]
Most likely another issue is that the ThreadPoolMetric does not add metrics for thread pools that are created on demand.
Fixes#2472
Signed-off-by: Wouter Born <github@maindrain.net>