river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Trasuk <tras...@stratuscom.com>
Subject Re: Latest Java release causes runtime exception
Date Fri, 22 Feb 2013 16:53:32 GMT

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


Mime
View raw message