[
https://issues.apache.org/jira/browse/LOG4J2-2025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16142704#comment-16142704
]
Ibrahim M. Ghazal commented on LOG4J2-2025:
-------------------------------------------
Yes, performance will be an issue. We need this for some third party libraries
that use JUL internally instead of using a logging abstraction, so we don't
have much choice (apart from stitching together logs from two files).
It could be worked around by calling
{{java.util.logging.Logger.getLogger(name).setLevel(level)}} when setting log4j
logger levels, but I'm not sure if that would apply only to the current
application in Tomcat or if it would affect the global JUL state. I'll
investigate.
I don't understand what you mean by {{having the java.util.logging.Handler be a
replacement for the Log4j-core Logger}}. Can you elaborate?
> 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)
