On Feb 10, 2013, at 404PM, Mark Brouwer wrote: > Hi Dennis
Hi Mark, Glad to see your input on the list. > , > > On 2/5/13 6:39 PM, Dennis Reedy wrote: >> This also happens with updates to Java 1.6 (u39). The fix looks to >> besimple. The Levels class seems to be the issue. Unless I'm missing >> something, it seems straight forward enough the create a custom level >> without using the ClassReplacingObjectOutputStream and the LevelData >> approach. I modified Levels (attached on my reply), rebuilt and >> everything seems to load successfully. Without this fix I have a >> complete show stopper for some of my installations. >> >> I'd like to request that this gets fixed ASAP and a new release >> produced. >> > > The reason for code is not some sort of code fetish I believe, it allows for > the creation of a pure instance of java.util.logging.Level that allows for > deserialization in JVMs that have never seen the com.sun.jini.logging.Levels > class. It also allows to use of 'HANDLED' and 'FAILED' in configuration files > for java.util.logging by means of the Level.parse() method. The proposed > change breaks with all of this and therefore it doesn't seem a proper fix to > me. A few thoughts here: 1. Configuring custom levels is done by configuring the custom level's integer 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) 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. > > I did some tests with the latest JDK 1.7 and indeed Oracle broke the > serialized contract for Level, a quick look at the source code indicate they > introduced a field 'localizedLevelName' without making it transient. So > Oracle broke the contract and this should be reported as a bug against Java > SE. Note that in the source code thay also didn't add the @serial tag so I > really hope this is an oversight on their side. I did no further analysis on > what else they changed in the Level class or the rationale behind it. Thanks for doing that digging, sure looks like this needs to be reported as a bug. Regards Dennis
