[jira] [Comment Edited] (LOG4J2-2025) Support Tomcat JULI's per-webapp JUL logging by implementing java.util.logging.Handler

["Ralph Goers (JIRA)" <ji...@apache.org>]

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

Ralph Goers edited comment on LOG4J2-2025 at 8/25/17 5:19 PM:
--------------------------------------------------------------

I see an issue in this design. When the isLoggable method on the logger is called it will reflect the log level in the tomcat logging system. If you set the log level in tomcat to "FINEST" so that all log events are passed to Log4j then many log events will be created only to be dropped by Log4j, thus hurting performance. OTOH, if you set the tomcat level to the desired level then the log level on the Log4j logger really should just be set to TRACE as no filtering should be performed.

This is one place where I could see having the java.util.logging.Handler be a replacement for the Log4j-core Logger, although I haven't looked at what that would entail.

FWIW, if we took this approach I would just add it to log4j-jul since it would just be an alternate way to wire jul to core.


was (Author: ralph.goers@dslextreme.com):
I see an issue in this design. When the isLoggable method on the logger is called it will reflect the log level in the tomcat logging system. If you set the log level in tomcat to "FINEST" so that all log events are passed to Log4j then many log events will be created only to be dropped by Log4j, thus hurting performance. OTOH, if you set the tomcat level to the desired level then the log level on the Log4j logger really should just be set to TRACE as no filtering should be performed.

This is one place where I could see having the java.util.logging.Handler be a replacement for the Log4j-core Logger, although I haven't looked at what that would entail.

> Support Tomcat JULI's per-webapp JUL logging by implementing java.util.logging.Handler
> --------------------------------------------------------------------------------------
>
>                 Key: LOG4J2-2025
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-2025
>             Project: Log4j 2
>          Issue Type: Improvement
>          Components: JUL adapter
>    Affects Versions: 2.8.2
>         Environment: Tomcat 8.5.20, Oracle Java 1.8.0_144
>            Reporter: Ibrahim M. Ghazal
>            Priority: Minor
>
> On most servlet containers, the only way to redirect JUL calls to Log4j is by setting the {{java.util.logging.manager=org.apache.logging.log4j.jul.LogManager}} system property *globally*. This often breaks the native logging of the container, and could also break other apps on the same container do not use Log4j 2. This also requires changing the container's settings and cannot be expressed in the app itself.
> Another approach (used by slf4j) is to implement {{java.util.logging.Handler}} and then install this handler at the root logger, either programmatically by calling {{LogManager.getLogManager().getLogger("").addHandler(...)}} or by changing logging.properties at the JRE level. This also breaks the container's native logging and other apps, but in different ways than LogManager. I do not advocate this approach, but it's useful to know about it as a background for this feature request.
> (tl;dr: It's impossible to reliably redirect JUL from a webapp without creating a mess).
> Thankfully, Tomcat has a solution for this: Tomcat [JULI|https://tomcat.apache.org/tomcat-8.5-doc/logging.html] allows per-webapp configuration by adding a {{WEB-INF/classes/logging.properties}} file with {{handlers=some.custom.Handler}} inside it. This will redirect JUL calls from this webapp (and this webapp only) to that handler, and that handler then can redirect to Log4j.
> In short: Add a {{java.util.logging.Handler}} implementation that redirects to Log4j so that webapps can use Tomcat's per-webapp configuration and avoid the JUL mess.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)