[ 
https://issues.apache.org/jira/browse/RIVER-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13584361#comment-13584361
 ] 

Dennis Reedy commented on RIVER-416:
------------------------------------

Okay, on the name vs level number, creating the new CustomLevel first does 
work. I indeed did miss that line, thanks.

However, reading the LogRecord back in results in a CNFE if the JVM does not 
have either jsk-platform.jar, or the serialized LogRecord is not annotated with 
an available codebase that has com.sun.jini.logging.Levels$CustomLevel. So in 
your scenario above, the Logging process would have a dependency on River. 

Now, if CustomLevel is not created first (or even exists), and a new Level is 
created (using Level.parse()) that has as its level and name 550 and 600 
(respectively HANDLED and FAILED), this all works fine. What we get is:

{code}
logger.log(Levels.HANDLED, "Don't worry, I handled it")
{code}

Emits:

{code}
550: Don't worry, I handled it
{code}

So, IMO these are the options:

# Accept a new runtime dependency for River to get Levels.HANDLED and 
Levels.FAILED working with names & level numbers
# Live with 550 and 600
# Continue looking into creating a *real* Level that does not require a runtime 
dependency 


                
> 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

Reply via email to