river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Reedy <dennis.re...@gmail.com>
Subject Re: Latest Java release causes runtime exception
Date Sun, 10 Feb 2013 21:39:46 GMT

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

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), 
# written. The levels that can be set are as follows:
#  SEVERE (highest value) 
#  INFO 
#  600    (FAILED custom-defined level)
#  550    (HANDLED custom-defined level)
#  FINE 
#  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.


View raw message