You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by "Nick Williams (JIRA)" <ji...@apache.org> on 2013/09/01 00:54:52 UTC
[jira] [Commented] (LOG4J2-359) Log4jServletContextListener does
not work on Weblogic 12.1.1 (12c) with web-app version "2.5"
[ 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-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org