[
https://issues.apache.org/jira/browse/LOG4J2-608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14137207#comment-14137207
]
Remko Popma commented on LOG4J2-608:
------------------------------------
This Jira is marked as resolved but there may still be a few loose ends.
How are custom JUL levels handled?
* It is not a problem if the initial version does not support custom JUL
levels, but we should clarify this in the JUL component page.
* If we decide to initially not support custom JUL log levels, is the
implementation complete? What happens if an application uses a custom JUL level
anyway? Does an exception get thrown, or is the event ignored, or does the log
level get rounded up/down the the nearest built-in level, or is some fixed
Log4j level used?
What is the component name for log4j-jul? Is it a Bridge or an Adapter? I
recently added a link to "JUL Bridge" in the left-hand navigation menu on the
web site, if that is wrong we should change that link...
The component page does not reflect some of the recent changes
* The title is still JDK Logging Adaptor
* The component page mentions that the thread ID, sequence number and level
name are stored in the ThreadContext map for every log event, but in the
current implementation this is no longer the case.
* Let's mention how we handle custom JUL log levels.
I'm thinking to do more performance testing to see what the throughput and
latency difference is with the different logging APIs: log4j-api, JUL, commons
logging and slf4j. Now that we are not creating a LogRecord for every logger
call and not using the ThreadContext map, I expect the JUL performance to be
pretty close to log4j-api. Nice!
> 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]
