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
