[
https://issues.apache.org/jira/browse/RIVER-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13575726#comment-13575726
]
Robert Gibson commented on RIVER-416:
-------------------------------------
Not sure the suggested fix is quite correct, as anybody who serializes the
CustomLevel will be unable to deserialize it without the current version of
River in the classpath.
I would suggest something like this instead
{code}
private static Level createLevel(String name,
int value,
String resourceBundleName) {
new CustomLevel(name, value, resourceBundleName);
// Recent Java versions correctly return a Level object instead of the
// custom sub-class, but old versions will just give the CustomLevel
// back again
final Level parse = Level.parse (Integer.toString (value));
if (parse.getClass ().equals (Level.class)) {
return parse;
} else {
// ... otherwise use previous approach
}
}
{code}
> The com.sun.jini.logging.Levels class produces a RuntimeException with the
> latest version of Java
> -------------------------------------------------------------------------------------------------
>
> Key: RIVER-416
> URL: https://issues.apache.org/jira/browse/RIVER-416
> Project: River
> Issue Type: Bug
> Components: com_sun_jini_logging
> Affects Versions: River_2.2.0
> Reporter: Dennis Reedy
> Priority: Blocker
> Attachments: Levels.java
>
>
> The com.sun.jini.logging.Levels class produces a RuntimeException with the
> latest version of Java (both 1.6 and 1.7). The issue surrounds creation of
> custom java.util.logging.Level. The current implementation uses a
> ClassReplacingObjectOutputStream and the LevelData approach. By removing this
> approach and creating a subclass of java.util.logging.Level the issue gets
> resolved.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
