logging-log4j-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Calmus <m...@calmus.org>
Subject Re: problems with web app and JndiContextSelector
Date Wed, 06 Aug 2014 16:39:44 GMT
After extensive trial and error I think I have things boiled down. In my
list "works" means that I see logging. For some there may be caveats.

All tests were run using Weblogic 10.3.6 (a Servlet 2.5 container) running
on Java 7. There were no difference when using Log4j 2.0 versus 2.0.1.

When I load the log4j libraries as a part of the server's startup classes
(out current preferred configuration with Log4j 1.2.x):

1) Standard web-app configuration with configuration file specified in
web.xml does not work
2) Configured with JndiContextSelector as the Log4jContextSelector system
property it doesn't work when I have things configured correctly. If I
exclude the JNDI lookup environment properties I get an error in the System
log, but logging works.

Removing the Log4j libraries from System startup and instead bundle them
with the application (no other changes)
Scenario 1 above now works.
The JNDI configuration does not work.




On Fri, Aug 1, 2014 at 3:16 PM, Mike Calmus <mike@calmus.org> wrote:

> We're using a Servlet 2.5 container and configuration. I added the
> Log4jContextSelector environment variable to the container startup as well
> as loading all the Log4j 2.0 jars with the container. I added the following
> items to my web.xml:
>
>   <context-param>
>     <param-name>isLog4jContextSelectorNamed</param-name>
>     <param-value>true</param-value>
>   </context-param>
>   <context-param>
>     <param-name>log4jContextName</param-name>
>     <param-value>myapp</param-value>
>   </context-param>
>   <context-param>
>     <param-name>log4jConfiguration</param-name>
>
> <param-value>file:///${sys:projectprops}/myapp/default/log4j2.xml</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>
> With just this, logging works fine, but I get an error when the JNDI
> lookup fails.
>
>   <env-entry>
>     <description>Sets the logging context for the web-app</description>
>     <env-entry-name>log4j/context-name</env-entry-name>
>     <env-entry-type>java.lang.String</env-entry-type>
>     <env-entry-value>myapp</env-entry-value>
>   </env-entry>
> The JNDI lookup error goes away but logging stops working.
>
> I also tried adding the following with no change in results.
>
>   <env-entry>
>     <description>URL for configuring log4j context</description>
>     <env-entry-name>log4j/configuration-resource</env-entry-name>
>     <env-entry-type>java.lang.String</env-entry-type>
>
> <env-entry-value>file:///${sys:projectprops}/myapp/default/log4j2.xml</env-entry-value>
>   </env-entry>
>
>
> On Tue, Jul 29, 2014 at 11:37 AM, Ralph Goers <ralph.goers@dslextreme.com>
> wrote:
>
>> The best would be a sample project that demonstrates the problem. At a
>> minimum I would think the web.xml and log4j 2 configuration.
>>
>> Ralph
>>
>> On Jul 29, 2014, at 5:47 AM, Mike Calmus <mike@calmus.org> wrote:
>>
>> > I am having problems moving our web app over to Log4j 2.0 using JNDI
>> > lookups. I followed the configuration documentation and am not getting
>> any
>> > errors, but nothing is being logged to my configured appenders.
>> Weirdly, if
>> > I remove the JNDI env-entry configuration from web.xml logging seems to
>> > work, albeit with the expected NameNotFoundException in the server
>> output.
>> >
>> > One possibly relevant configuration difference is that we load the log4j
>> > jar files as part of server startup so each app doesn't have to load
>> them.
>> >
>> > Any ideas? What configuration can I provide to help troubleshoot?
>> >
>> > Thanks.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>
>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message