Uploaded image for project: 'Log4j 2'
  1. Log4j 2
  2. LOG4J2-608

Add support for a java.util.logging bridge.

    Details

    • Type: New Feature
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.1
    • Component/s: JUL adapter
    • Labels:
      None
    • Environment:

      OpenJDK 1.6, 1.7, 1.8, and any other JDK 1.6+ implementations if possible

      Description

      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.

      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.

      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.

      Questions

      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.

      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?

      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.

        Attachments

        1. 608-1.0.patch
          43 kB
          Matt Sicker

          Activity

            People

            • Assignee:
              jvz Matt Sicker
              Reporter:
              jvz Matt Sicker
            • Votes:
              1 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: