On Feb 10, 2013, at 801PM, Mark Brouwer wrote: > 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.
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. > 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. Yes, it's an implementation detail, but the practical matter is that the class is in jsk-platform.jar. If the project chooses to change the content of jsk-platform.jar, or even move to a different logger framework (which IMO would be a better thing to do, JUL is limited and abstractions such as SLF4J offer much greater opportunities to support River in production settings, but that a topic for a different discussion), then River can adapt to that change. But for now, since jsk-platform.jar is a requirement for clients, and this class is in the classpath, I really dont see how this can derail. > > > >> 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. It appears that com.sun.jini.logging.Levels is included in many jars, one of which is jsk-dl.jar. How would this fail? > >> >> 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. Will do Regards Dennis
