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

[Daniel Fuchs]

On 9/12/14 1:55 PM, Peter Levart wrote:

On 09/12/2014 12:45 PM, Daniel Fuchs wrote:

However the listeners are to be invoked in the same order they have been
added.

I am still unconvinced this is worth the additional
complexity it would bring to the implementation.
The deprecated methods were using HashMap to store listeners,
and therefore the order in which listeners were invoked was also
undefined. Nobody has ever complained.

What about using a synchronized LinkedHashMap<ListenerAction,
ListenerAction>() with the following double-purpose inner class:

     private static final class ListenerAction implements
PrivilegedAction<Void> {
         private final Runnable listener;
         private final AccessControlContext acc;

         ListenerAction(Runnable listener, AccessControlContext acc) {
             this.listener = listener;
             this.acc = acc;
         }

         void invoke() {
             if (acc == null) {
                 run();
             } else {
                 AccessController.doPrivileged(this, acc);
             }
         }

         // not to be run() directly - use invoke() instead
         @Override
         public Void run() {
             listener.run();
             return null;
         }

         @Override
         public int hashCode() {
             return System.identityHashCode(listener);
         }

         @Override
         public boolean equals(Object obj) {
             return (obj instanceof ListenerAction) &&
                    ((ListenerAction) obj).listener == listener;
         }
     }

yes - that's what I'm calling the additional complexity ;-)

-- daniel

(http://hg.openjdk.java.net/jdk8u/jdk8u-dev/jdk/file/3ae82f0c6b31/src/share/classes/java/util/logging/LogManager.java#l1431)

I'd rather run the listeners in try/catch and throw the 1st exception at
the end.
Defining the 1st however requires obeying the order the listeners have
been added.
As far as I see there is no documentation how the listeners are supposed
to behave or be invoked.

We could do that - invoke all listeners and rethrow the exception
caught by the first listener that failed (on the basis that if any other
listener subsequently fails it may be because the previous listener
has left the system in an inconsistent state, and that therefore
the first exception caught has 'more value' than the others).

I am not completely convinced this is a better behavior than
simply stopping invoking listeners at the first exception.
I wonder if there would be a good wording to say that listeners
are not supposed to throw, but that if they do, the exceptions
will be propagated...

You're probably right. But in case you changed your mind, you could
rethrow the 1st exception thrown, with possible further exceptions added
to it a suppressed exceptions...

Regards, Peter

best regards,

-- daniel