[
https://issues.apache.org/jira/browse/RIVER-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13584292#comment-13584292
]
Robert Gibson commented on RIVER-416:
-------------------------------------
My contention is that code can receive Levels.HANDLED or Levels.FAILED without
having a dependency on com.sun.jini.logging.
It's true that the code which does
{code}
logger.log(Levels.HANDLED, "Don't worry, I handled it")
{code}
does have a dependency on Levels. But the logging framework that actually
handles it doesn't (currently).
{noformat}
-------------- -----------------
| Jini process | - - - - | Logging process |
-------------- -----------------
{noformat}
Any time you write an out-of-process LogHandler this is what you do. Maybe I'm
not being very clear? If you don't believe me, just serialise Levels.HANDLED to
a file and then try and read it back without jsk-dl.jar available. You can
currently do it without any error.
> 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
