DecoratingCA may not extend MonitoringCA

DecoratingCA does delegate a new CM to its delegate. Thus this issue is resolved?

No, it's still in progress by Mauro. We're in discussion, where to put MonitoringCA into the hierarchy. While we talk about "the" CA for a component it is in fact a CA chain, e.g.:

new ThreadLocalCA(new CachingCA(new HotSwappingCA(new CICA(XY.class))))

only the inner CA instance must have a monitor!

• Jörg

yes - the DecoratingCA has been changed to delegate the new CM.

But the issue outstanding is how to make only the innermost CA have the monitor. I think this would require adding a method

ComponentMonitorStrategy#currentMonitor()

ATM there is no way to have access to the current monitor of the degated CA which is injected into another CA.
Only be extending MonitoringCA can we do that.

Objections to adding the new method to CMS?

All the time I thougt, that currentMonitor() is part of CMS ... because it was part of the DecoratingCA! Yes; you'll need it in CMS.

That's where the communication wires crossed

Added currentMonitor() to ComponentMonitorStrategy.
Removed inheritance of DelegatingCA from MonitoringCA.
DelegatingCA#currentMonitor() will return the current monitor of the delegate
if it supports CMS. If not, it will throw a PicoIntrospectionException,

DefaultPC also implements ComponentMonitorStrategy:
currentMonitor() is retrieved in order from CAF, CAs and child containers.
If not found in any, it will throw a PicoIntrospectionException.