RFR: 8043306 - Provide a replacement for the API that allowed to listen for LogManager configuration changes

[Daniel Fuchs]

Hi Stanimir,

On 9/12/14 9:47 AM, Stanimir Simeonoff wrote:
> Hello,
>
> Just a note, acc is going to leak the context class loader until the
> listener is removed. That should be noted in the documentation.

Good point. But I expect the concrete listener class will also be 
usually loaded by the context class loader - so isn't that kind of 
expected anyway?
I didn't want to stuff too many implementation details into the spec.
Maybe that could be an API note however.
Would anyone be able to suggest a good wording?

> Also if there is a runtime exception during run() of a listener it will
> block any other listeners to be invoked and the exception is going to be
> propagated past readConfiguration(). I suppose that's ok however the
> listeners are to be invoked in a 'random' order depending on their
> identityHashCode. So if there is an exception in the last registered
> there is no guarantee to invoke even the 1st added listener. The entire
> process is not deterministic which is not ok for listeners invocation.

The 'old' deprecated code was already like that.
This doesn't mean we shouldn't try to make it better - but I have
to ask whether it's worth the trouble.

Are there applications where there will be several listeners?
And if there are - shouldn't these listener run their code in a
try { } catch ( ) { } to ensure that the exception will be
logged - or rather reported - where it belong?

IMO the only thing we could do here is to silently drop any
runtime/exception or error, which I am a bit reluctant to do;
I believe it's the concrete implementation of the listener
which should take care of that.

best regards,

-- daniel

>
> Stanimir
>