[
https://issues.apache.org/jira/browse/LOG4J2-608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Sicker closed LOG4J2-608.
------------------------------
> Add support for a java.util.logging bridge.
> -------------------------------------------
>
> Key: LOG4J2-608
> URL: https://issues.apache.org/jira/browse/LOG4J2-608
> Project: Log4j 2
> Issue Type: New Feature
> Components: JUL adapter
> Environment: OpenJDK 1.6, 1.7, 1.8, and any other JDK 1.6+
> implementations if possible
> Reporter: Matt Sicker
> Assignee: Matt Sicker
> Fix For: 2.1
>
> Attachments: 608-1.0.patch
>
>
> The JDK1.4 bridge from SLF4J is rather simplistic and looks error-prone
> (e.g., you need to manually start and stop the Handler). What I'd like is a
> Handler that includes Markers based on the log Level (which can be more than
> the built-in ones) along with a custom LogManager implementation.
> h2. The easy way
> For the easier use case of the user setting the {{java.util.logging.manager}}
> system property ahead of time to the correct LogManager implementation, this
> won't be too hard to support. I recommend extending the Logger class and
> having them log directly to their corresponding Log4j Logger instance. The
> custom LogManager should return these instances.
> For compatibility with existing Logger objects, the custom Handler class
> should be used to pass along log messages.
> h2. Reflection hackery
> Due to the lousy API that JDK1.4 gives you, there will need to be a bit of
> reflection hacking to inject itself into the LogManager and any existing
> Loggers. Because you can't replace a class instance via reflection, existing
> Logger references will have to use the Handler. The global LogManager can be
> replaced reflectively, but all its named Loggers should be transferred over
> to the new LogManager without losing any log messages during the process.
> After the LogManager is swapped out, any other calls to
> {{Logger.getLogger(String)}} or {{LogManager.getLogger(String)}} should
> return the Log4j implementations instead.
> h2. Questions
> h3. Level correspondence
> Which levels should the JUL levels correspond to? Here's my proposal:
> ||JUL Level Name||JUL Level Range||Corresponding Log4j Level||
> |ALL|{{Integer.MIN_VALUE}}|ALL|
> |FINEST|≤300|TRACE|
> |FINER|301 to 400|DEBUG|
> |FINE|401 to 500|DEBUG|
> |CONFIG|501 to 700|INFO|
> |INFO|701 to 800|INFO|
> |WARNING|801 to 900|WARN|
> |SEVERE|901 to 1000|ERROR|
> |?|>1000|FATAL|
> |OFF|{{Integer.MAX_VALUE}}|OFF|
> Along with those levels (which could also use the custom levels for
> non-standard ones), I'd also like to use markers here (if it makes sense).
> What I'm thinking is a parent marker named "java.util.logging", and then
> every JUL level (custom or standard) gets its own marker as well. This would
> be useful since JUL defines more levels than we have by default.
> h3. JUL config vs. Log4j config
> Should we override the JUL Loggers' levels based on the Log4j Loggers'
> levels? Or should we allow the JUL config to override the Log4j config?
> Should we allow JUL settings to be imported? Or should they be overridden by
> Log4j's configuration?
> h3. JDK compatibility
> What other JDKs are still out there for 1.6+ besides OpenJDK? The reflection
> hackery I have so far has fallbacks to try and find compatible methods or
> fields based on types, but who knows how different the JUL implementations
> could be? Plus, there could be licensing issues with alternative JDK code
> such that we can't effectively reverse engineer their implementations.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
