[jira] [Created] (LOG4J2-608) Add support for a java.util.logging bridge.

[Matt Sicker (JIRA)]

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)

[Matt Sicker (JIRA)]

[ https://issues.apache.org/jira/browse/LOG4J2-608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Sicker updated LOG4J2-608:
-------------------------------

Attachment: 608-1.0.patch

Here's what I did today. Almost seems to work (at least using OpenJDK 1.8) just fine. Such evil usage of reflection. ;)

Post by Matt Sicker (JIRA)
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
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
||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)

[Matt Sicker (JIRA)]

[ https://issues.apache.org/jira/browse/LOG4J2-608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Sicker updated LOG4J2-608:
-------------------------------

Fix Version/s: 2.1

Post by Matt Sicker (JIRA)
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
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
||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)

[Christian Moen (JIRA)]

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

Thanks.

Post by Matt Sicker (JIRA)
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
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
||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)

[Ralph Goers (JIRA)]

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

Ralph Goers commented on LOG4J2-608:
------------------------------------

1. I have yet to look at Matt's code on this but from reading the details above I think he has a good handle on the problem. The designers of java.util.logging simply did a very poor job in terms of allowing other implementations. Feel free to take a look at how LogManager is implemented to see what the problems are.

2. Yes you can use the SLF4J bride and then bridge to Log4j2. That is why we haven't made this a high priority (yet).

3. Look at the source for java.util.logging and see if you can come up with a better idea on how to implement a bridge.

Post by Matt Sicker (JIRA)
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
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
||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)

[Remko Popma (JIRA)]

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

Remko Popma commented on LOG4J2-608:
------------------------------------

About log levels, would it be an idea for the log4j JUL bridge to define custom log4j2 log levels FINEST, FINER, FINE and CONFIG (intLevel TBD) to correspond to the JUL levels? If we implement LOG4J2-589, these log levels can then be used in log4j2 configuration to control filtering.

Different question: the description mentions the "easy case of setting the {{java.util.logging.manager}} system property ahead of time to replace the LogManager", and in addition a more difficult case to use reflection to transfer "existing Loggers". I'm not sure that I understand the need to replace existing Loggers. When would this be necessary?

Perhaps I am misunderstanding this, but I am worried that transferring from one JUL logging implementation to another, while the application is running, would be a lot of work and would be more fragile than a simple replace-at-startup implementation. Would it not be enough to ask users to set the {{java.util.logging.manager}} system property in advance if they want logging to the JUL API to be redirected to the Logj2 implementation?

Post by Matt Sicker (JIRA)
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
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
||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)

[Matt Sicker (JIRA)]

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

Matt Sicker commented on LOG4J2-608:
------------------------------------

It would be easier to require setting the system property. The alternative is to iterate over all the active Loggers and modifying their Handlers. That method requires a bit more reflection.

In regards to the #3 question, one way that would help a lot would be checking the differences of implementation between OpenJDK 1.6, 1.7, and 1.8, as well as any other common JDKs (like IBM's) if possible.

Post by Matt Sicker (JIRA)
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
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
||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)

[Remko Popma (JIRA)]

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

Remko Popma commented on LOG4J2-608:
------------------------------------

Okay, then I propose we start with requiring users to set the system property to help us get a stable first version of JUL support out. So we would postpone the reflection-based mechanism until we get user feedback that there is a need for switching active Loggers in flight. Thoughts?

Post by Matt Sicker (JIRA)
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
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
||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)

[Matt Sicker (JIRA)]

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

Matt Sicker commented on LOG4J2-608:
------------------------------------

That would work better as an initial implementation.

Post by Matt Sicker (JIRA)
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
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
||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)

[Matt Sicker (JIRA)]

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

Matt Sicker commented on LOG4J2-608:
------------------------------------

So this is pretty neat. If you use this implementation of LogManager along with setting {{status="debug"}} in the configuration, then you see additional JMX log messages!

Post by Matt Sicker (JIRA)
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
||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)

[Matt Sicker (JIRA)]

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

Matt Sicker commented on LOG4J2-608:
------------------------------------

Got an implementation going in the LOG4J2-608 branch in git.

Post by Matt Sicker (JIRA)
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
||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)

[Matt Sicker (JIRA)]

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

Matt Sicker commented on LOG4J2-608:
------------------------------------

Updated branch to not require log4j-core. Documentation inside branch still requires updating, though.

Post by Matt Sicker (JIRA)
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
||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)

[Remko Popma (JIRA)]

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

Remko Popma commented on LOG4J2-608:
------------------------------------

This may just be personal preference, but would log4j-jul not be a better module name than log4j-jdk? I see people on StackOverflow using the abbreviation JUL a lot when talking about java util logging. To me log4j-jdk suggests something else, like either a java logging development kit, or something to do with the java SDK as a whole (not just logging).

(Sorry, haven't had a chance to look at the code yet, just came home from traveling.)

Post by Matt Sicker (JIRA)
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
||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)

[Christian Moen (JIRA)]

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

Christian Moen commented on LOG4J2-608:
---------------------------------------

Great to see work on this! I personally also like {{log4j-jul}} better than {{log4j-jdk}}.

Post by Matt Sicker (JIRA)
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
||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)

[Matt Sicker (JIRA)]

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

Matt Sicker commented on LOG4J2-608:
------------------------------------

Renamed to log4j-jul and pushed changes.

Post by Matt Sicker (JIRA)
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
||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)

[Matt Sicker (JIRA)]

[ https://issues.apache.org/jira/browse/LOG4J2-608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matt Sicker resolved LOG4J2-608.
--------------------------------
Resolution: Fixed

Merged into master.

Post by Matt Sicker (JIRA)
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
||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)

[Remko Popma (JIRA)]

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

Post by Matt Sicker (JIRA)
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
||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)

[Matt Sicker (JIRA)]

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

Matt Sicker commented on LOG4J2-608:
------------------------------------

Custom levels, from what I remember, were mapped to the closest Log4j level, but that might not be the case anymore. Right now, there's a strategy interface for converting the JDK levels, and I provided a default implementation that included two custom Log4j levels (CONFIG and FINEST if I remember correctly). So yes, agreed on documentation updates.

The ThreadContext stuff does need to be updated, and that was initially removed due to performance concerns (which makes me think that Pax Logging needs to make that an optional feature themselves).

As to the name, it's usually a good idea to stick to the naming pattern of the API in question. For instance, an adaptor for Log4j 2 API would be called a Log4j Provider. SLF4J has its own naming pattern. The JDK one does not appear to have such a scheme, so maybe something such as "Java Util Logging LogManager" or "JUL LogManager". The idea at least is to emphasize the LogManager as you do indeed have to set a system property to override the default one, and the ability to dynamically take over the existing LogManager, while interesting, is a very complex topic which would most likely introduce various problems if there are conflicting LogManagers configured other than the default.

Post by Matt Sicker (JIRA)
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
||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)

[Ralph Goers (JIRA)]

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

Ralph Goers commented on LOG4J2-608:
------------------------------------

Are we talking about the component name that appears on the left nav of the web site? I dislike anything with "LogManager" in the name. Leave that for an explanation on the component's page. Personally, I would call it JUL Adapter.

Post by Matt Sicker (JIRA)
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
||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)

[Remko Popma (JIRA)]

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

Remko Popma commented on LOG4J2-608:
------------------------------------

I'm fine with JUL Adapter.

About the ThreadContext stuff, I am happy with the current implementation (no use of ThreadContext), but the component page still explains the old implementation. I think we should just update the docs and remove that section.

Post by Matt Sicker (JIRA)
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
||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)