Matt Sicker created LOG4J2-608:
----------------------------------
Summary: 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: JDK 1.4 adapter
Environment: OpenJDK 1.6, 1.7, 1.8, and any other JDK 1.6+
implementations if possible
Reporter: Matt Sicker
Assignee: Matt Sicker
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.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
