[
https://issues.apache.org/jira/browse/LOG4J2-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13755625#comment-13755625
]
Nick Williams commented on LOG4J2-359:
--------------------------------------
So. Many. Questions. And stop editing comments hours later! :P ;-)
I'm going to address the ordering issue, first. You are correct that,
_according to the spec_, the order that SCIs are executed in is unspecified.
This is an oversight that I [intend to lobby hard to have corrected in Servlet
3.2|https://java.net/jira/browse/SERVLET_SPEC-79] (and judging by the Tomcat
mailing list, I'll have some backup). However, in practice, this is not
actually the case. If you read the responses to the message you link to, you
will see that Tomcat orders SCIs according to the web-fragment ordering. This
is legal, because the spec doesn't prohibit it, it just doesn't require it.
Furthermore, five of the eight major containers (Tomcat, TomEE, JBoss,
WebLogic, and WebSphere) order SCIs according to the web-fragment ordering.
After further inspection, it appears that GlassFish, Jetty, and Resin _do_
execute them in "random" order (*ugh*). However, with that said, this "random"
order is actually alphabetic by JAR name, and log4j*.jar comes before
spring*.jar. So, *most* users will *never* see a problem with ordering.
_(Yes, I'm operating under the assumption that Spring's SCI is the one we're
most concerned about. I've yet to see any other SCIs in any other third-party
libraries or in containers that could result in inadvertent initialization of
Log4j. I am, nevertheless, filing improvement requests with GlassFish, Jetty,
and Resin asking them to follow what other containers do.)_
With that out of the way, I'm not saying it's "invalid to specify a servlet
context listener in the {{web.xml}}" in Servlet 3.0+. I'm saying it's invalid
(but harmless) to re-define *Log4j's* listener in {{web.xml}} in Servlet 3.0+.
I'm not completely opposed to changing the exception to a warning, but I don't
agree with the idea, either. Added in the SCI, it ensures that the filter runs
before any filters in {{web.xml}}. It also ensures that it runs before any
filters in other SCIs (with the ordering issue kept in mind, of course). The
exception lets the user know in no uncertain terms that Log4j might not work
correctly because the filter wasn't defined early enough, and that they can
very simply fix the issue by taking the filter out of their {{web.xml}}. That's
my stance.
Web applications cannot define their own {{ServletContainerInitializer}}
implementations without putting them in a JAR file within WEB-INF/lib, so we
can't reasonably expect a user to do this. An annotation is a potential idea,
but I just don't see the necessity. The existing code _is_ capable of
initializing correctly. Just because there was a bug doesn't mean the whole
concept is fatally flawed. I *strongly* stand behind the idea of the user not
having to do *anything* other than add {{log4j2.xml}} to their application
unless they need to customize behavior (which they can do using the context
parameters; they don't need to override the existing initializer to do this).
If they _really_ need to stop Log4j from auto-initializing in Servlet 3.0+, we
don't have to provide a mechanism to support this. They can use
{{<absolute-ordering>}} in {{web.xml}} to exclude the Log4j web-fragment. I'm
okay with adding an example of doing this to the documentation.
I *do* agree that the initializer should not do anything if the Log4j JARs come
from the container and the application isn't actually using Log4j. What is the
*correct* way to detect this? I believe this is sufficient, but I could be
wrong:
- If the Log4j context parameters are specified, the application obviously
intends to use Log4j, so initialize it.
- If the Log4j context parameters are not specified but one of the standard
configuration files is present, the application obviously intends to use Log4j,
so initialize it.
- Otherwise, don't initialize Log4j.
If this is correct, this leads me to a question. How do I look for the
"standard configuration" without Log4j initializing the null or default
configuration if it doesn't find one?
> Log4jServletContextListener does not work on Weblogic 12.1.1 (12c) with
> web-app version "2.5"
> ---------------------------------------------------------------------------------------------
>
> Key: LOG4J2-359
> URL: https://issues.apache.org/jira/browse/LOG4J2-359
> Project: Log4j 2
> Issue Type: Bug
> Affects Versions: 2.0-beta8
> Reporter: Abhinav Shah
> Assignee: Nick Williams
> Fix For: 2.0-beta9
>
> Attachments: LOG4J2-359.patch, Log4jServletContainerInitializer.java,
> Log4jServletContainerInitializerTest.java
>
>
> I have Weblogic 12c running. My web-app is version "2.5".
> Following is a snippet from my web.xml
> {code:xml}
> <web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xmlns="http://java.sun.com/xml/ns/javaee";
> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
> http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd";
> id="WebApp_ID" version="2.5">
> <display-name>pec-service</display-name>
> <context-param>
> <param-name>log4jConfiguration</param-name>
> <param-value>file:/C:/log4j/dev.log4j.xml</param-value>
> </context-param>
> <listener>
>
> <listener-class>org.apache.logging.log4j.core.web.Log4jServletContextListener</listener-class>
>
> </listener>
> <filter>
> <filter-name>log4jServletFilter</filter-name>
>
> <filter-class>org.apache.logging.log4j.core.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>
>
> </web-app>
> {code}
> However, on my server startup I am getting the following error -
> {code}
> <Aug 16, 2013 3:12:32 PM PDT> <Warning> <HTTP> <BEA-101162> <User defined
> listener org.apache.logging.log4j.core.web.Log4jServletContextListener
> failed: java.lang.IllegalStateException: Context destroyed before it was
> initialized..
> java.lang.IllegalStateException: Context destroyed before it was initialized.
> at
> org.apache.logging.log4j.core.web.Log4jServletContextListener.contextDestroyed(Log4jServletContextListener.java:51)
> at
> weblogic.servlet.internal.EventsManager$FireContextListenerAction.run(EventsManager.java:583)
> at
> weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
> at
> weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
> at
> weblogic.servlet.provider.WlsSubjectHandle.run(WlsSubjectHandle.java:57)
> Truncated. see log file for complete stacktrace
> >
> <Aug 16, 2013 3:12:32 PM PDT> <Error> <Deployer> <BEA-149265> <Failure
> occurred in the execution of deployment request with ID "1376691143681" for
> task "2". Error is: "weblogic.application.ModuleException"
> weblogic.application.ModuleException
> at
> weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java:1708)
> at weblogic.servlet.internal.WebAppModule.start(WebAppModule.java:781)
> at
> weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:213)
> at
> weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:208)
> at
> weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:35)
> Truncated. see log file for complete stacktrace
> Caused By: java.lang.NullPointerException
> at
> org.apache.logging.log4j.core.web.Log4jServletContainerInitializer.onStartup(Log4jServletContainerInitializer.java:44)
> at
> weblogic.servlet.internal.WebAppServletContext.initContainerInitializer(WebAppServletContext.java:1271)
> at
> weblogic.servlet.internal.WebAppServletContext.initContainerInitializers(WebAppServletContext.java:1229)
> at
> weblogic.servlet.internal.WebAppServletContext.preloadResources(WebAppServletContext.java:1726)
> at
> weblogic.servlet.internal.WebAppServletContext.start(WebAppServletContext.java:2740)
> Truncated. see log file for complete stacktrace
> >
> <Aug 16, 2013 3:12:32 PM PDT> <Error> <Deployer> <BEA-149202> <Encountered an
> exception while attempting to commit the 7 task for the application
> "_auto_generated_ear_".>
> <Aug 16, 2013 3:12:32 PM PDT> <Warning> <Deployer> <BEA-149004> <Failures
> were detected while initiating start task for application
> "_auto_generated_ear_".>
> <Aug 16, 2013 3:12:32 PM PDT> <Warning> <Deployer> <BEA-149078> <Stack trace
> for message 149004
> weblogic.application.ModuleException
> at
> weblogic.servlet.internal.WebAppModule.startContexts(WebAppModule.java:1708)
> at weblogic.servlet.internal.WebAppModule.start(WebAppModule.java:781)
> at
> weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:213)
> at
> weblogic.application.internal.flow.ModuleStateDriver$3.next(ModuleStateDriver.java:208)
> at
> weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:35)
> Truncated. see log file for complete stacktrace
> Caused By: java.lang.NullPointerException
> at
> org.apache.logging.log4j.core.web.Log4jServletContainerInitializer.onStartup(Log4jServletContainerInitializer.java:44)
> at
> weblogic.servlet.internal.WebAppServletContext.initContainerInitializer(WebAppServletContext.java:1271)
> at
> weblogic.servlet.internal.WebAppServletContext.initContainerInitializers(WebAppServletContext.java:1229)
> at
> weblogic.servlet.internal.WebAppServletContext.preloadResources(WebAppServletContext.java:1726)
> at
> weblogic.servlet.internal.WebAppServletContext.start(WebAppServletContext.java:2740)
> Truncated. see log file for complete stacktrace
> {code}
> If I remove the listener & the filter, it works fine.
> {color:red}
> I did some research and found that even though the web-app is version "2.5",
> the {code}Log4jServletContainerInitializer{code} is getting invoked.
> {color}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-dev-h...@logging.apache.org
