[
https://issues.apache.org/jira/browse/LOG4J2-2624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17095983#comment-17095983
]
Robert Turner edited comment on LOG4J2-2624 at 4/30/20, 12:55 AM:
------------------------------------------------------------------
I've been looking into what I believe is a similar problem. If I control the
initialization order of log4j filter as per the above description, then
substitutions in the config file do not work with WebLookup. After digging
through the code, I notice that the initialization sequence is different.
In the case where {{Log4jServletContainerInitializer}} performs the
initialization, it retrieves the {{Log4jWebLifeCycle}} and then invokes
{{start()}} on it. In the case where you manually control the intialization
sequence and rely on {{Log4jServletFilter}} to perform the initialization,
{{start()}} is never explicitly invoked on the {{Log4jWebLifeCycle}} object. As
such, the initialization of Log4j happens in an uncontrolled fashion, and
without the "logger context" being set -- which means there is no way for
{{webLookup}} to function correctly during the initialization sequence (unless
somehow you independently set the context as you trigger the Log4j operations
that will cause the logging system to be initialized.
I think a possible solution is to ensure that {{start()}} is invoked during the
initial construction of the {{Log4jWebInitializerImpl}} object, possibly when
it is created by {{WebLoggerContextUtils. getWebLifeCycle()}}, however, before
calling {{start()}} the "logger context" will have to be "set" by causing
{{ContextAnchor.THREAD_CONTEXT.set(this.loggerContext);}} to be invoked with
the {{servletContext}} object.
I haven't tried such a modification to log4j yet, but I believe it something
like my suggestion should resolve the issue.
(BTW, I came by this problem as we were noticing shutdown issues, and we didn't
have logging during shutdown due to the problem described here:
http://instantdelay.com/articles/log4j-shutdown-problems.html -- after
controlling the initialization order (ala servlet 2.5) to ensure correct
shutdown ordering, we ended up with the log file being named incorrectly -- our
log4j.xml contains the following for the fileName
{{fileName="${sys:catalina.base}/logs/${web:contextPath}.log"}} )
was (Author: [email protected]):
I've been looking into what I believe is a similar problem. If I control the
initialization order of log4j filter as per the above description, then
substitutions in the config file do not work with the WebLookup. After digging
through the code, I notice that the initialization sequence is different.
In the case where {{Log4jServletContainerInitializer}} performs the
initialization, it retrieves the {{Log4jWebLifeCycle}} and then invokes
{{start()}} on it. In the case where you manually control the intialization
sequence and rely on {{Log4jServletFilter}} to perform the initialization,
{{start()}} is never explicitly invoked on the {{Log4jWebLifeCycle}} object. As
such, the initialization of Log4j happens in an uncontrolled fashion, and
without the "logger context" being set -- which means there is no way for
{{webLookup}} to function correctly during the initialization sequence (unless
somehow you independently set the context as you trigger the Log4j operations
that will cause the logging system to be initialized.
I think a possible solution is to ensure that {{start()}} is invoked during the
initial construction of the {{Log4jWebInitializerImpl}} object, possibly when
it is created by {{WebLoggerContextUtils. getWebLifeCycle()}}, however, before
calling {{start()}} the "logger context" will have to be "set" by causing
{{ContextAnchor.THREAD_CONTEXT.set(this.loggerContext);}} to be invoked with
the {{servletContext}} object.
I haven't tried such a modification to log4j yet, but I believe it something
like my suggestion should resolve the issue.
(BTW, I came by this problem as we were noticing shutdown issues, and we didn't
have logging during shutdown due to the problem described here:
http://instantdelay.com/articles/log4j-shutdown-problems.html -- after
controlling the initialization order (ala servlet 2.5) to ensure correct
shutdown ordering, we ended up with the log file being named incorrectly -- our
log4j.xml contains the following for the fileName
{{fileName="${sys:catalina.base}/logs/${web:contextPath}.log"}} )
> ${web:rootDir} not working in weblogic 12c
> ------------------------------------------
>
> Key: LOG4J2-2624
> URL: https://issues.apache.org/jira/browse/LOG4J2-2624
> Project: Log4j 2
> Issue Type: Bug
> Affects Versions: 2.11.0
> Reporter: gaurav
> Priority: Blocker
>
> The web lookup - ${web:rootDir} seems to cause problems on weblogic 12c
> deployment.
> I suspect that the _*web-lookup plugin is not initialized*_ when weblogic
> requests the logger at the start of deployment and is unable to create the
> file.
> What I've done -
> *1. Added slf4j in weblogic preferred packages of weblogic.xml.*
> <wls:package-name>org.slf4j.*</wls:package-name>
> *2. log4j-web dependency is present in classpath.*
> *3.web.xml contains following:-*
> <context-param>
> <param-name>isLog4jAutoInitializationDisabled</param-name>
> <param-value>true</param-value>
> </context-param>
> <listener>
>
> <listener-class>org.apache.logging.log4j.web.Log4jServletContextListener</listener-class>
> </listener>
> <filter>
> <filter-name>log4jServletFilter</filter-name>
>
> <filter-class>org.apache.logging.log4j.web.Log4jServletFilter</filter-class>
> </filter>
> <filter-mapping>
> <filter-name>log4jServletFilter</filter-name>
> <url-pattern>/*</url-pattern>
> <dispatcher>REQUEST</dispatcher>
> <dispatcher>FORWARD</dispatcher>
> <dispatcher>INCLUDE</dispatcher>
> <dispatcher>ERROR</dispatcher>
> </filter-mapping>
> *Note - Log4jServletContextListener is placed before all listeners.
> -Have attached stacktrace for your reference.
> [^stacktrace.txt]
> Please assist.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
