Hi Dennis,
On 2/10/13 10:39 PM, Dennis Reedy wrote:
A few thoughts here:
1. Configuring custom levels is done by configuring the custom
level'sinteger level value (this can be done for all levels, not just custom
levels). For example, taking a look at the
examples.hello/config/logging.properties we see:
# Below, turn the individual loggers 'on/off' by setting
# their levels to a lower value. For example, if a logger's
# level is set to INFO, then only those log records that
# are at the levels INFO, WARNING, or SEVERE will be written.
# Whereas, if that logger's level is set to FINE, then all
# log records that are at the levels FINE, 550 (HANDLED),
# 600 (FAILED), CONFIG, INFO, WARNING, or SEVERE will be
# written. The levels that can be set are as follows:
#
# SEVERE (highest value)
# WARNING
# INFO
# CONFIG
# 600 (FAILED custom-defined level)
# 550 (HANDLED custom-defined level)
# FINE
# FINER
# FINEST (lowest value)
Even if you have subclasses of java.util.logging.Level you can refer
them by the name in the logging configuration file as long as these have
been instantiated before the LogManager reads the configuration file.
For that reason the com.sun.jini.logging.LogManager refers to
Levels.HANDLED and Levels.HANDLED. So therefore I believe the only
reason left for that magic is to prevent from these levels being
serialized and not having the requirement to have the implementing
classes available at the JVm where they are deserialized or to have them
as part of a download JAR.
>
2. Since com.sun.jini.logging.Levels is in jsk-platform.jar, and
> jsk-platform.jar is a requirement to have in the JVM's classpath, when
> would the chance be that a JVM would have never seen the
> com.sun.jini.logging.Levels class? Seems as if any JVM that uses River
> would have this class in it's classpath. Also,
> com.sun.jini.logging.Levels is not itself serializable, so I'm not
> sure the scenario you describe (if I'm understanding it correctly)
> could happen.
It is an implementation detail of the platform and not part of the
public API. So if you assume these HANDLED and FAILED levels might be
serialized in some form (assuming they were implemented as a subclass)
then would need to be part of a download JAR file associated with your
particular platform implementation.
As java.util.logging.LogRecord is also serializable and has Level as a
serialized field I believe the person who wrote
com.sun.jini.logging.Levels went to great lengths to stay in the mindset
of the Java logging framework and increase the chance a LogRecord could
be deserialized at as many locations as possible.
Thanks for doing that digging, sure looks like this needs to be reported as a
bug.
>
Please do so, I will try to do the same if I figured out how to do that
these days.
BTW the current code could be made more robust, i.e. guard it against a
contract violation by Java itself, by keeping the same logic as there is
right now, but if that fails do what you in your patch:
} catch (Exception e) {
... create here as subclass of java.util.logging.Level
}
That subclass should have a serialVersionUID though and a
readObjectNoData() for the purist.
Regards,
--
Mark Brouwer
