You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Dennis Reedy <de...@gmail.com> on 2013/02/05 18:20:53 UTC
Latest Java release causes runtime exception
Major problem here. With the latest Java update (java version "1.7.0_13") the following occurs:
Caused by: java.lang.RuntimeException: Unexpected exception
at com.sun.jini.logging.Levels.createLevel(Levels.java:142)
at com.sun.jini.logging.Levels.<clinit>(Levels.java:52)
... 18 more
Caused by: java.io.EOFException
at java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2557)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1294)
at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1950)
at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1874)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1756)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1326)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
at com.sun.jini.logging.Levels.createLevel(Levels.java:138)
Re: Latest Java release causes runtime exception
Posted by Mark Brouwer <ma...@marbro.org>.
Hi Dennis,
BTW I'm glad you reported this issue, because I used these logging
classes from the starter kit in many non Jini projects too and these
are
all likely to blow up soon if people install the latest Java SE, which
I'm
not that happy with.
On 2/11/13 2:20 AM, Dennis Reedy wrote:
>
>> Even if you have subclasses of java.util.logging.Level you can
>> refer
them by the name in the logging configuration file as long as these
have
been instantiated before the LogManager reads the configuration file.
>
> Sure its possible to do that, AFAIK, the current code does not do
> this. The approach thus far (as referenced in the documentation and
> examples) is to use the level value, not the name. Furthermore, by
> configuring the level value(s) (either 600 or 550) loggers emit as
> they
> should with the current approach.
c.s.j.u.LogManager allows you to refer by the names, but that would
assume people configure this LogManager for their JVM:
/** Creates an instance of this class. */
public LogManager() {
/* Refer to the levels to make sure that they are defined */
Levels.FAILED.toString();
Levels.HANDLED.toString();
}
Personally I always use the names because number don't say me that
much.
> It appears that com.sun.jini.logging.Levels is included in many jars,
> one of which is jsk-dl.jar. How would this fail?
Didn't know they were in the various -dl.jar files but that is because
I
only use the source and not the distribution. Most likely they are
there
because the smart proxy uses them directly. So there is likely no
chance it would derail, nevertheless IMHO it is still a valid approach
they made the log level appear as if it is a real instance of
java.util.logging.Level
I'm only trying to give a rationale for the current implementation for
which I see no reason to ditch it, except for making it more robust to
work around a bug that slipped into Java SE.
Regards,
--
Mark Brouwer
Re: Latest Java release causes runtime exception
Posted by Dennis Reedy <de...@gmail.com>.
On Feb 10, 2013, at 801PM, Mark Brouwer wrote:
> Hi Dennis,
>
> On 2/10/13 10:39 PM, Dennis Reedy wrote:
>>
>>
>> A few thoughts here:
>>
>
>> 1. Configuring custom levels is done by configuring the custom
>> level'sinteger 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)
>>
>
> Even if you have subclasses of java.util.logging.Level you can refer them by the name in the logging configuration file as long as these have been instantiated before the LogManager reads the configuration file.
Sure its possible to do that, AFAIK, the current code does not do this. The approach thus far (as referenced in the documentation and examples) is to use the level value, not the name. Furthermore, by configuring the level value(s) (either 600 or 550) loggers emit as they should with the current approach.
> For that reason the com.sun.jini.logging.LogManager refers to Levels.HANDLED and Levels.HANDLED. So therefore I believe the only reason left for that magic is to prevent from these levels being serialized and not having the requirement to have the implementing classes available at the JVm where they are deserialized or to have them as part of a download JAR.
Yes, it's an implementation detail, but the practical matter is that the class is in jsk-platform.jar. If the project chooses to change the content of jsk-platform.jar, or even move to a different logger framework (which IMO would be a better thing to do, JUL is limited and abstractions such as SLF4J offer much greater opportunities to support River in production settings, but that a topic for a different discussion), then River can adapt to that change. But for now, since jsk-platform.jar is a requirement for clients, and this class is in the classpath, I really dont see how this can derail.
>
> >
>> 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.
>
> It is an implementation detail of the platform and not part of the public API. So if you assume these HANDLED and FAILED levels might be serialized in some form (assuming they were implemented as a subclass) then would need to be part of a download JAR file associated with your particular platform implementation.
>
> As java.util.logging.LogRecord is also serializable and has Level as a serialized field I believe the person who wrote com.sun.jini.logging.Levels went to great lengths to stay in the mindset of the Java logging framework and increase the chance a LogRecord could be deserialized at as many locations as possible.
It appears that com.sun.jini.logging.Levels is included in many jars, one of which is jsk-dl.jar. How would this fail?
>
>>
>> Thanks for doing that digging, sure looks like this needs to be reported as a bug.
> >
>
> Please do so, I will try to do the same if I figured out how to do that these days.
Will do
Regards
Dennis
Re: Latest Java release causes runtime exception
Posted by Mark Brouwer <ma...@marbro.org>.
Hi Dennis,
On 2/10/13 10:39 PM, Dennis Reedy wrote:
>
>
> A few thoughts here:
>
> 1. Configuring custom levels is done by configuring the custom
> level'sinteger 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)
>
Even if you have subclasses of java.util.logging.Level you can refer
them by the name in the logging configuration file as long as these have
been instantiated before the LogManager reads the configuration file.
For that reason the com.sun.jini.logging.LogManager refers to
Levels.HANDLED and Levels.HANDLED. So therefore I believe the only
reason left for that magic is to prevent from these levels being
serialized and not having the requirement to have the implementing
classes available at the JVm where they are deserialized or to have them
as part of a download JAR.
>
> 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.
It is an implementation detail of the platform and not part of the
public API. So if you assume these HANDLED and FAILED levels might be
serialized in some form (assuming they were implemented as a subclass)
then would need to be part of a download JAR file associated with your
particular platform implementation.
As java.util.logging.LogRecord is also serializable and has Level as a
serialized field I believe the person who wrote
com.sun.jini.logging.Levels went to great lengths to stay in the mindset
of the Java logging framework and increase the chance a LogRecord could
be deserialized at as many locations as possible.
>
> Thanks for doing that digging, sure looks like this needs to be reported as a bug.
>
Please do so, I will try to do the same if I figured out how to do that
these days.
BTW the current code could be made more robust, i.e. guard it against a
contract violation by Java itself, by keeping the same logic as there is
right now, but if that fails do what you in your patch:
} catch (Exception e) {
... create here as subclass of java.util.logging.Level
}
That subclass should have a serialVersionUID though and a
readObjectNoData() for the purist.
Regards,
--
Mark Brouwer
Re: Latest Java release causes runtime exception
Posted by Dennis Reedy <de...@gmail.com>.
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
Re: Latest Java release causes runtime exception
Posted by Dennis Reedy <de...@gmail.com>.
Mark,
Apologies for leaving an answer to your question below blank, I didn't catch it until now.
> Do you have a bug id for http://bugs.sun.com/ for this issue, because to prevent from duplicate reports I tried to search it. But that search function in Sun/Oracle bug database is severely broken for quite a while now.
No, I do not have a bug id for this, feel free to create a report.
Thanks again for the additional robustness in your patch.
Regards
Dennis
Re: Latest Java release causes runtime exception
Posted by Dennis Reedy <de...@gmail.com>.
On Mar 12, 2013, at 1233PM, Mark Brouwer wrote:
>
>
> https://issues.apache.org/jira/browse/RIVER-416 contains a patch against the trunk that could be applied, as well as the complete source code. My j.u.l.Levels implementation was based on the initial submission from Sun to Apache so it lacks the reformatting that was done in a previous submit. I'm not closely monitoring what has changed with regard to the project conventions, but I still assume the coding style in place is the same as effective within Sun. I can even remember some fierce discussions about tabs versus spaces in the beginning but as I see there are still tabs and spaces that stayed the same too ;-)
> IMHO maintaining the some coding style would ease in taking and giving of code between various codebases out there in the field.
I dont agree with the maintaining the current coding style, at times I find much of the code base to be unreadable (until it is formatted). Many of the conventions just dont seem to make sense anymore. For example, line length of 80 characters. Perhaps this made sense when out display resolution was 640x780, (recall the conventions were last updated in 1999), but not for today. I dont even want to start the discussion on tabs vs spaces (I use spaces).
>
> The above solution has been tested on various JDKs, I did verify the actual objects created (all real instances of Level) and analyzed the serialized byte streams and this does really does seems to do the trick. At least I found it an interesting journey through the serialization specification ...
The approach I had provided also was tested on various JDKs. However, I'm glad to accept your patch
Thanks
Dennis
Re: Latest Java release causes runtime exception
Posted by Mark Brouwer <ma...@marbro.org>.
Hi Dennis,
As I had some time to fix my own code as result of the change in the
serialized form of j.u.l.Level I had to look a bit better what has been
going on with j.u.l.Level and how to solve it. As a result I implemented
a more robust solution than that currently in trunk, more about that later.
On 2/22/13 5:38 PM, Dennis Reedy wrote:
> 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.
>
Looking in most recent source code for JDK 1.7 and 1.6 it seems quite
clear that the field localizedLevelName should have been declared
transient, as there is no particular need to carry it around in the
serialized form. JDK 1.8 ea doesn't contain these changes yet, so the
Levels class worked without problems over there.
Do you have a bug id for http://bugs.sun.com/ for this issue, because to
prevent from duplicate reports I tried to search it. But that search
function in Sun/Oracle bug database is severely broken for quite a while
now.
However I have to correct my statement that Oracle breached the
serialized contract for j.u.l.Level. If the field localizedLevelName was
an intentional change it should have been documented with the @serial
tag, but according to section 5.6.2 of the the serialization
specification
(http://docs.oracle.com/javase/7/docs/platform/serialization/spec/version.html#6678)
adding a field is a compatible change and therefore the code in
com.sun.jini.logging.Levels shouldn't have failed. Although mentioned as
an incompatible change removing a field in a later version of a class
should not break deserialization with an older version either as in such
a case the default value is just assigned (although the state of the
object might be broken).
The real problems lies with c.s.j.l.Levels.LevelData as the class
c.s.j.l.Levels.ClassReplacingObjectOutputStream makes through the
writeClassDescriptor method the ObjectOutputStream 'believe' that
LevelData is effectively a Level instance. The class descriptor is
therefore in case of the latest JDK 1.6. and 1.7 telling there are 4
fields available in Level. LevelData is only able to provide 3 of these
(reading the 4th field through reflection doesn't seem to fail). I
analyzed the byte stream of what was serialized and although it was
mentioned there are 4 fields only values for 3 of them were actually
provided. Deserialization therefore failed because the class descriptor
is really expecting 4 values in the stream while there are only 3, hence
the EOF execption (in this particular case).
The solution is that LevelData must *really* mimic the serialized form
of the Level class. This can be accomplished by controlling the
serialized fields for LevelData by setting serialPersistentFields:
/** Fields from {@link Level} that needs to be serialized. */
private static final ObjectStreamField[] serialPersistentFields =
ObjectStreamClass.lookup(Level.class).getFields();
By implementing the following writeObject method on LevelData, the
values for the know fields of Level can be provides. This code will be
able to handle further evolution of the Level class as well:
/**
* Controls the writing of the actual fields to mimic those
* available in {@link Level}.
*/
private void writeObject(java.io.ObjectOutputStream out)
throws IOException
{
ObjectOutputStream.PutField putFields = out.putFields();
for (int i = 0 ; i < serialPersistentFields.length ; i++) {
ObjectStreamField field = serialPersistentFields[i];
if (field.getName().equals("name")) {
putFields.put(field.getName(), name);
}
else if (field.getName().equals("resourceBundleName")) {
putFields.put(field.getName(), resourceBundleName);
}
else if (field.getName().equals("value")) {
putFields.put(field.getName(), value);
}
// if a field name is unknown it looks like the Level class
// evolved, but we are in no position to provide a
// meaningful value, so therefore don't provide a value as
// the putField object already has the default values set
// for all fields as returned by serialPersistentFields
}
out.writeFields();
}
https://issues.apache.org/jira/browse/RIVER-416 contains a patch against
the trunk that could be applied, as well as the complete source code. My
j.u.l.Levels implementation was based on the initial submission from Sun
to Apache so it lacks the reformatting that was done in a previous
submit. I'm not closely monitoring what has changed with regard to the
project conventions, but I still assume the coding style in place is the
same as effective within Sun. I can even remember some fierce
discussions about tabs versus spaces in the beginning but as I see there
are still tabs and spaces that stayed the same too ;-)
IMHO maintaining the some coding style would ease in taking and giving
of code between various codebases out there in the field.
The above solution has been tested on various JDKs, I did verify the
actual objects created (all real instances of Level) and analyzed the
serialized byte streams and this does really does seems to do the trick.
At least I found it an interesting journey through the serialization
specification ...
Regards,
--
Mark Brouwer
Re: Latest Java release causes runtime exception
Posted by Greg Trasuk <tr...@stratuscom.com>.
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
Re: Latest Java release causes runtime exception
Posted by Dennis Reedy <de...@gmail.com>.
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
Re: Latest Java release causes runtime exception
Posted by Mark Brouwer <ma...@marbro.org>.
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.
Regards,
--
Mark Brouwer
Re: Latest Java release causes runtime exception
Posted by Dennis Reedy <de...@gmail.com>.
On Feb 5, 2013, at 218PM, Greg Trasuk wrote:
>
>
> On Tue, 2013-02-05 at 12:39, Dennis Reedy wrote:
>> This also happens with updates to Java 1.6 (u39). The fix looks to be simple. 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.
>>
>
> Any committers on the list? Oh wait, aren't you one, Dennis :-)
Smart alec :)
>
> Actually, could you open a Jira ticket for this and attach your patch?
https://issues.apache.org/jira/browse/RIVER-416 has been created, modified file attached to the issue.
> I suspect that since it's a core library, we might be best to "Review
> then commit" on this one. I agree that a quick release is in order.
> Perhaps we should branch from the last stable release and patch/release
> that? Opinions anyone?
Re: Latest Java release causes runtime exception
Posted by Dennis Reedy <de...@asarian-tech.com>.
On Feb 6, 2013, at 918AM, Peter Firmstone wrote:
> On 6/02/2013 11:49 PM, Dennis Reedy wrote:
>> On Feb 5, 2013, at 218PM, Greg Trasuk wrote:
>>>
>>> Actually, could you open a Jira ticket for this and attach your patch?
>>> I suspect that since it's a core library, we might be best to "Review
>>> then commit" on this one. I agree that a quick release is in order.
>>> Perhaps we should branch from the last stable release and patch/release
>>> that? Opinions anyone?
>> I have a real production issue with this, so I'll go ahead and branch. What is the latest stable release branch?
>>
>> Thanks
>>
>> Dennis
>>
> The last stable svn version I branched off for river qa refactoring, sorry can't remember the version number, but you can look it up on svn, a recent qa refactoring svb version was even better, until I broke it again recently. Be careful though LookupLocator serial form has broken compatibility, so you'll need to fix that before releasing.
I was planning on applying the fix to trunk, and into the 2.2 branch, and tagging the change as 2.2.1.
Dennis
Re: Latest Java release causes runtime exception
Posted by Peter Firmstone <ji...@zeus.net.au>.
On 6/02/2013 11:49 PM, Dennis Reedy wrote:
> On Feb 5, 2013, at 218PM, Greg Trasuk wrote:
>>
>> Actually, could you open a Jira ticket for this and attach your patch?
>> I suspect that since it's a core library, we might be best to "Review
>> then commit" on this one. I agree that a quick release is in order.
>> Perhaps we should branch from the last stable release and patch/release
>> that? Opinions anyone?
> I have a real production issue with this, so I'll go ahead and branch. What is the latest stable release branch?
>
> Thanks
>
> Dennis
>
The last stable svn version I branched off for river qa refactoring,
sorry can't remember the version number, but you can look it up on svn,
a recent qa refactoring svb version was even better, until I broke it
again recently. Be careful though LookupLocator serial form has broken
compatibility, so you'll need to fix that before releasing.
What's becoming more obvious is that the concurrency bugs are still
there, I don't think the recently commited code is at issue at all,
instead it's brought existing bugs to the surface, it seems to be
occurring more often with modern processors. I can't reproduce these
bugs on my old 4 way sparc, it passes, but the Jenkins builds keep
experiencing failures, concurrency bugs are very hard to debug.
Regards,
Peter.
Re: Latest Java release causes runtime exception
Posted by Greg Trasuk <tr...@stratuscom.com>.
On Wed, 2013-02-06 at 08:49, Dennis Reedy wrote:
> On Feb 5, 2013, at 218PM, Greg Trasuk wrote:
> >
> >
> > Actually, could you open a Jira ticket for this and attach your patch?
> > I suspect that since it's a core library, we might be best to "Review
> > then commit" on this one. I agree that a quick release is in order.
> > Perhaps we should branch from the last stable release and patch/release
> > that? Opinions anyone?
>
> I have a real production issue with this, so I'll go ahead and branch. What is the latest stable release branch?
>
The last branch that was released was 2.2.0. Assuming that you're
running the released branch, then it seems like we ought to branch from
there and create a 2.2.1 release. In addition, we should apply your
patch to the current development branch as well.
By the way, I also commented on the patch - There's a statement about
"Object uniqueness property" in the java.util.logging.Level javadocs
that I'm not sure what it means, but I suspect it needs something added
o the com.sun.jini.logging.Levels implementation.
Cheers,
Greg.
> Thanks
>
> Dennis
>
Re: Latest Java release causes runtime exception
Posted by Dennis Reedy <de...@gmail.com>.
On Feb 5, 2013, at 218PM, Greg Trasuk wrote:
>
>
> Actually, could you open a Jira ticket for this and attach your patch?
> I suspect that since it's a core library, we might be best to "Review
> then commit" on this one. I agree that a quick release is in order.
> Perhaps we should branch from the last stable release and patch/release
> that? Opinions anyone?
I have a real production issue with this, so I'll go ahead and branch. What is the latest stable release branch?
Thanks
Dennis
Re: Latest Java release causes runtime exception
Posted by Greg Trasuk <tr...@stratuscom.com>.
On Tue, 2013-02-05 at 12:39, Dennis Reedy wrote:
> This also happens with updates to Java 1.6 (u39). The fix looks to be simple. 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.
>
Any committers on the list? Oh wait, aren't you one, Dennis :-)
Actually, could you open a Jira ticket for this and attach your patch?
I suspect that since it's a core library, we might be best to "Review
then commit" on this one. I agree that a quick release is in order.
Perhaps we should branch from the last stable release and patch/release
that? Opinions anyone?
Cheers,
Greg,
> Thanks
>
> Dennis
>
>
> /*
> * Licensed to the Apache Software Foundation (ASF) under one
> * or more contributor license agreements. See the NOTICE file
> * distributed with this work for additional information
> * regarding copyright ownership. The ASF licenses this file
> * to you under the Apache License, Version 2.0 (the
> * "License"); you may not use this file except in compliance
> * with the License. You may obtain a copy of the License at
> *
> * http://www.apache.org/licenses/LICENSE-2.0
> *
> * Unless required by applicable law or agreed to in writing, software
> * distributed under the License is distributed on an "AS IS" BASIS,
> * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> * See the License for the specific language governing permissions and
> * limitations under the License.
> */
>
> package com.sun.jini.logging;
>
> import java.io.ByteArrayInputStream;
> import java.io.ByteArrayOutputStream;
> import java.io.IOException;
> import java.io.ObjectInputStream;
> import java.io.ObjectOutputStream;
> import java.io.ObjectStreamClass;
> import java.io.OutputStream;
> import java.io.Serializable;
> import java.lang.String;
> import java.util.logging.Level;
>
> /**
> * Defines additional {@link Level} values. <p>
> * <p/>
> * See the {@link LogManager} class for one way to use the <code>FAILED</code>
> * and <code>HANDLED</code> logging levels in standard logging configuration
> * files.
> *
> * @author Sun Microsystems, Inc.
> * @since 2.0
> */
> public class Levels {
>
> /**
> * <code>FAILED</code> is a message level indicating that a facility has
> * experienced a failure that it will reflect to its caller. <p>
> * <p/>
> * <code>FAILED</code> messages are intended to provide users with
> * information about failures produced by internal components in order to
> * assist with debugging problems in systems with multiple components. This
> * level is initialized to <code>600</code>.
> */
> public static final Level FAILED = createLevel("FAILED", 600, null);
>
> /**
> * <code>HANDLED</code> is a message level indicating that a facility has
> * detected a failure that it will take steps to handle without reflecting
> * the failure to its caller. <p>
> * <p/>
> * <code>HANDLED</code> messages are intended to provide users with
> * information about failures detected by internal components in order to
> * assist with debugging problems in systems with multiple components. This
> * level is initialized to <code>550</code>.
> */
> public static final Level HANDLED = createLevel("HANDLED", 550, null);
>
> /**
> * This class cannot be instantiated.
> */
> private Levels() {
> throw new AssertionError("This class cannot be instantiated");
> }
>
>
> /**
> * Creates an instance of the Level class. This method works around the
> * fact that there is no public constructor for the Level class by
> * constructing the serialized form for an instance with the specified
> * field values and deserializing it.
> */
> private static Level createLevel(String name,
> int value,
> String resourceBundleName) {
> return new CustomLevel(name, value, resourceBundleName);
> }
>
> static class CustomLevel extends Level {
> CustomLevel(String name, int value, String resourceBundleName) {
> super(name, value, resourceBundleName);
> }
> }
> }
>
Re: Latest Java release causes runtime exception
Posted by Dennis Reedy <de...@gmail.com>.
This also happens with updates to Java 1.6 (u39). The fix looks to be simple. 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.
Thanks
Dennis
/*
* Licensed to the Apache Software Foundation (ASF) under one
* or more contributor license agreements. See the NOTICE file
* distributed with this work for additional information
* regarding copyright ownership. The ASF licenses this file
* to you under the Apache License, Version 2.0 (the
* "License"); you may not use this file except in compliance
* with the License. You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package com.sun.jini.logging;
import java.io.ByteArrayInputStream;
import java.io.ByteArrayOutputStream;
import java.io.IOException;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;
import java.io.ObjectStreamClass;
import java.io.OutputStream;
import java.io.Serializable;
import java.lang.String;
import java.util.logging.Level;
/**
* Defines additional {@link Level} values. <p>
* <p/>
* See the {@link LogManager} class for one way to use the <code>FAILED</code>
* and <code>HANDLED</code> logging levels in standard logging configuration
* files.
*
* @author Sun Microsystems, Inc.
* @since 2.0
*/
public class Levels {
/**
* <code>FAILED</code> is a message level indicating that a facility has
* experienced a failure that it will reflect to its caller. <p>
* <p/>
* <code>FAILED</code> messages are intended to provide users with
* information about failures produced by internal components in order to
* assist with debugging problems in systems with multiple components. This
* level is initialized to <code>600</code>.
*/
public static final Level FAILED = createLevel("FAILED", 600, null);
/**
* <code>HANDLED</code> is a message level indicating that a facility has
* detected a failure that it will take steps to handle without reflecting
* the failure to its caller. <p>
* <p/>
* <code>HANDLED</code> messages are intended to provide users with
* information about failures detected by internal components in order to
* assist with debugging problems in systems with multiple components. This
* level is initialized to <code>550</code>.
*/
public static final Level HANDLED = createLevel("HANDLED", 550, null);
/**
* This class cannot be instantiated.
*/
private Levels() {
throw new AssertionError("This class cannot be instantiated");
}
/**
* Creates an instance of the Level class. This method works around the
* fact that there is no public constructor for the Level class by
* constructing the serialized form for an instance with the specified
* field values and deserializing it.
*/
private static Level createLevel(String name,
int value,
String resourceBundleName) {
return new CustomLevel(name, value, resourceBundleName);
}
static class CustomLevel extends Level {
CustomLevel(String name, int value, String resourceBundleName) {
super(name, value, resourceBundleName);
}
}
}
Re: Latest Java release causes runtime exception
Posted by "Jeremy R. Easton-Marks" <J....@gmail.com>.
We have been seeing all sorts of weird things with 1.7 in a variety of
libraries in our lab and have decided to stick with 1.6 for the time being.
I don't think 1.7 was really ready to go out the door when it did. I am
keeping my fingers crossed for 1.7.1
Jeremy R. Easton-Marks
"être fort pour être utile"
On Tue, Feb 5, 2013 at 11:20 AM, Dennis Reedy <de...@gmail.com>wrote:
> Major problem here. With the latest Java update (java version "1.7.0_13")
> the following occurs:
>
> Caused by: java.lang.RuntimeException: Unexpected exception
> at com.sun.jini.logging.Levels.createLevel(Levels.java:142)
> at com.sun.jini.logging.Levels.<clinit>(Levels.java:52)
> ... 18 more
> Caused by: java.io.EOFException
> at
> java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2557)
> at
> java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1294)
> at
> java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1950)
> at
> java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1874)
> at
> java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1756)
> at
> java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1326)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348)
> at com.sun.jini.logging.Levels.createLevel(Levels.java:138)
>
>
>