Reading the conclusion to this thread, and the JIRA comments around it, I'm struck by a few things:
1 - At no time did I see anything that read as "you're wrong". All discussion was about the merits of one approach over another. 1a - A couple of times, people came back with statements that I would translate as "hmm, seems I'm wrong. Thanks for the input", or "perhaps I misunderstood". 2 - The discussion seems to have drawn a few old friends out of the woodwork. 3 - As a result of all these discussions, we collectively arrived at a better solution than we probably would have, individually (at least I'm assuming so; I haven't looked closely at the result). 4 - The very fact that we had this problem and the discussion tells me that River is out there in the Real World! This is a great example of civil discourse and collegiality, and really validates our commit-then-review policies. Great work all round! Now let's ship it! Cheers, Greg Trasuk. On Fri, 2013-02-22 at 11:38, Dennis Reedy wrote: > 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
