[jira] [Commented] (LOG4J2-3577) Log4j2 configuration during servlet context initialization does not work on Websphere Liberty appserver

["ASF subversion and git services (Jira)" <ji...@apache.org>]

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

ASF subversion and git services commented on LOG4J2-3577:
---------------------------------------------------------

Commit 80aae217962109e86e7edba0f87a266b989fce37 in logging-log4j2's branch refs/heads/dependabot/maven/com.fasterxml.woodstox-woodstox-core-6.3.1 from Piotr P. Karwasz
[ https://gitbox.apache.org/repos/asf?p=logging-log4j2.git;h=80aae21796 ]

[LOG4J2-3577] Use classloader provided by servlet context

Since we advertise a Servlet 4.0 requirement, we can use
`ServletContext#getClassLoader()` from Servlet 3.0 to retrieve the
correct logger context for the given servlet context.

> Log4j2 configuration during servlet context initialization does not work on Websphere Liberty appserver
> -------------------------------------------------------------------------------------------------------
>
>                 Key: LOG4J2-3577
>                 URL: https://issues.apache.org/jira/browse/LOG4J2-3577
>             Project: Log4j 2
>          Issue Type: Bug
>          Components: Configuration
>    Affects Versions: 2.17.1
>         Environment: I am using Log4j 2.17.1 on Websphere Liberty 21.0.0.8.
>            Reporter: Carl Froneberger
>            Assignee: Piotr Karwasz
>            Priority: Major
>         Attachments: Log4jWebInitializerImpl.java
>
>
> In my web application, log4j configures itself twice:
>  # before the servlet context is initialized
>  # during servlet context initialization
> (1) uses a log4j configuration that only consists of console appenders. (2) uses a full log4j configuration that consists of servlet appenders and servlet context lookups that would fail if initialized before the servlet context was available. The logger configuration from (2) should overwrite the logger configuration created in (1) for the rest of the application's lifecycle.
> However, this does not work on Websphere Liberty. Because Log4j associates a logger context with the classloader used to create it, the classloader used during (2) must be the same classloader that is used during the rest of the application's lifecycle.
> Liberty uses the following classloaders:
>  * before servlet context initialization: AppClassLoader
>  * during servlet context initialization: ThreadContextClassLoader
>  * the rest of the application lifecycle: AppClassLoader
> This means that log messages produced during the rest of the application lifecycle do not go through the full log4j configuration created in (2) because the configuration from (2) is associated with the ThreadContextClassLoader whereas the rest of the application uses the AppClassLoader. All messages during the rest of the application lifecycle are logged with the configuration created in (1) because they have the same classloader.
> To workaround this, I have had to modify the source of Log4jWebInitializerImpl:initializeNonJndi to check if the classloader is an instance of com.ibm.ws.classloading.internal.ThreadContextClassLoader. If it is, I pass null as the classloader to Configurator:initialize to allow it to resolve the classloader via other means, which it ultimately computes as the AppClassLoader.
> I have attached my edited version of Log4jWebInitializerImpl.java
> This works on all other application servers that I have tested on, such as Tomcat, Weblogic, and JBoss.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)