On Feb 10, 2013, at 404PM, Mark Brouwer wrote: > Hi Dennis, > > 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. > > 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.
Mark, After a couple of go arounds discussing this in Jira, I recalled what you said here, and adding support for the 'localizedLevelName' in the com.sun.jini.logging.Levels$LevelData class seems to do the trick. So my original suggestion to create a CustomLevel as a way to deal with this is being rolled back. The original approach of creating a *real* level that introduces no runtime requirements for River classes in a JVM that reads LogRecords that have either Levels.HANDLED and Levels.FAILED remains. Thanks Dennis
