Hi Dennis,
BTW I'm glad you reported this issue, because I used these logging
classes from the starter kit in many non Jini projects too and these
are
all likely to blow up soon if people install the latest Java SE, which
I'm
not that happy with.
On 2/11/13 2:20 AM, Dennis Reedy wrote:
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.
Sure its possible to do that, AFAIK, the current code does not do
this. The approach thus far (as referenced in the documentation and
examples) is to use the level value, not the name. Furthermore, by
configuring the level value(s) (either 600 or 550) loggers emit as
they
should with the current approach.
c.s.j.u.LogManager allows you to refer by the names, but that would
assume people configure this LogManager for their JVM:
/** Creates an instance of this class. */
public LogManager() {
/* Refer to the levels to make sure that they are defined */
Levels.FAILED.toString();
Levels.HANDLED.toString();
}
Personally I always use the names because number don't say me that
much.
It appears that com.sun.jini.logging.Levels is included in many jars,
one of which is jsk-dl.jar. How would this fail?
Didn't know they were in the various -dl.jar files but that is because
I
only use the source and not the distribution. Most likely they are
there
because the smart proxy uses them directly. So there is likely no
chance it would derail, nevertheless IMHO it is still a valid approach
they made the log level appear as if it is a real instance of
java.util.logging.Level
I'm only trying to give a rationale for the current implementation for
which I see no reason to ditch it, except for making it more robust to
work around a bug that slipped into Java SE.
Regards,
--
Mark Brouwer
