logging-log4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christian Moen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LOG4J2-608) Add support for a java.util.logging bridge.
Date Sat, 09 Aug 2014 14:50:11 GMT

    [ https://issues.apache.org/jira/browse/LOG4J2-608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14091775#comment-14091775

Christian Moen commented on LOG4J2-608:

Thanks for working on this.

A couple of questions:

# Is there any other way to bridge {{java.util.logging}} (JUL) to Log4j2 other than this?
# Is it possible to bridge JUL to SLF4J using SLF4J's bridge and then bridge SLF4J to Log4j2
using Log4j2's SLF4J bridge to effectively make a JUL to Log4j2 bridge?
# Is anything I can help with to help get this feature into Log4j2 version 2.1?


> 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
>            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
> 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|
> |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

To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

View raw message