[
https://issues.apache.org/jira/browse/RIVER-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13584379#comment-13584379
]
Robert Gibson commented on RIVER-416:
-------------------------------------
Strange, my tests with JDK >= 1.6.0_39 and 1.7.0_13 showed that Level.parse()
always returned an instance of exactly j.u.l.Level, never a sub-class, are you
seeing something different?
If recent JDKs (which are the only ones to exhibit this bug) do indeed always
return a Level, not a CustomLevel, then I maintain my suggestion from [my first
comment|https://issues.apache.org/jira/browse/RIVER-416?focusedCommentId=13575726&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13575726]
for a hybrid approach.
> 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
