Re: commons-logging problem
CATALINA_OPTS is more suitable here, though either one will work. Also, you can put the value into catalina.properties. 2009/10/9 niaouli : > > Hi, > Can you just tell me, please, if the option > -Dorg.apache.catalina.loader.WebappClassLoader.ENABLE_CLEAR_REFERENCES > should be put in JAVA_OPTS or in CATALINA_OPTS? > Thanks. > -- > View this message in context: > http://www.nabble.com/commons-logging-problem-tp21736872p25816008.html - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: commons-logging problem
Hi, Can you just tell me, please, if the option -Dorg.apache.catalina.loader.WebappClassLoader.ENABLE_CLEAR_REFERENCES should be put in JAVA_OPTS or in CATALINA_OPTS? Thanks. -- View this message in context: http://www.nabble.com/commons-logging-problem-tp21736872p25816008.html Sent from the Tomcat - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: commons-logging problem
Certainly putting commons-logging and log4j in the container's common/lib directory is the documented configuration. However this does not allow application-level logging for libraries used by the application like digester or spring that themselves use commons logging. The application log messages they generate then end up in the container's log files, and have to be enabled by changing the container's logging config. This is far from ideal. Hence my desire to install commons-logging in the application's WEB-INF/lib directory .. when you hit the problem I encountered. John. Gregor Schneider wrote: On Fri, Jan 30, 2009 at 8:33 PM, Rusty Wright wrote: Does that work reliably now? I was under the impression that it caused problems, but that may have been with a previous version of tomcat. That's why I asked my "where else" question; I was wondering if that's what he was thinking of. Since you're talking about TC 5.5, it's a definit yes. Take a look at http://tomcat.apache.org/tomcat-5.5-doc/logging.html I've got one 5.5-instance-running here, and it works like charm. Rgds Gregor - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: commons-logging problem
On Fri, Jan 30, 2009 at 8:33 PM, Rusty Wright wrote: > Does that work reliably now? I was under the impression that it caused > problems, but that may have been with a previous version of tomcat. That's > why I asked my "where else" question; I was wondering if that's what he was > thinking of. > Since you're talking about TC 5.5, it's a definit yes. Take a look at http://tomcat.apache.org/tomcat-5.5-doc/logging.html I've got one 5.5-instance-running here, and it works like charm. Rgds Gregor -- just because your paranoid, doesn't mean they're not after you... gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2 gpgp-key available @ http://pgpkeys.pca.dfn.de:11371 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: commons-logging problem
Does that work reliably now? I was under the impression that it caused problems, but
that may have been with a previous version of tomcat. That's why I asked my "where
else" question; I was wondering if that's what he was thinking of.
Gregor Schneider wrote:
On Fri, Jan 30, 2009 at 7:45 PM, Rusty Wright wrote:
John Holman wrote:
Also is it a supported configuration to use commons-logging and log4j in
WEB-INF/lib?
Where else would you put them?
i.e. ${CATALINA_HOME}/common/lib
Saves the hazzle to put them into each webapp.
Rgds
Gregor
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: commons-logging problem
On Fri, Jan 30, 2009 at 7:45 PM, Rusty Wright wrote:
> John Holman wrote:
>>
>> Also is it a supported configuration to use commons-logging and log4j in
>> WEB-INF/lib?
>
> Where else would you put them?
>
i.e. ${CATALINA_HOME}/common/lib
Saves the hazzle to put them into each webapp.
Rgds
Gregor
--
just because your paranoid, doesn't mean they're not after you...
gpgp-fp: 79A84FA526807026795E4209D3B3FE028B3170B2
gpgp-key available @ http://pgpkeys.pca.dfn.de:11371
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: commons-logging problem
John Holman wrote: Also is it a supported configuration to use commons-logging and log4j in WEB-INF/lib? Where else would you put them? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: commons-logging problem
> From: John Holman [mailto:j.g.hol...@qmul.ac.uk] > Subject: Re: commons-logging problem > > Doing this does make me a bit nervous though, as we've had > problems with PermGen memory exhaustion in the past. I think your nervousness is quite justified. > is it worth filing a bug report to pinpoint what's > going wrong in this particular case? Wouldn't hurt. At worst, it will be closed with a pointer to the original bug. > Also is it a supported configuration to use commons-logging > and log4j in WEB-INF/lib? That I don't know for sure, but I don't see why it wouldn't be o.k. AFAIK, commons-logging can be used with a variety of logging packages. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: commons-logging problem
Thank you - disabling the PermGen fix by setting org.apache.catalina.loader.WebappClassLoader.ENABLE_CLEAR_REFERENCES to false stops the exception from appearing, as you suggested. Doing this does make me a bit nervous though, as we've had problems with PermGen memory exhaustion in the past. It also suggests that this fix has problems of its own. I have a very simple test war that demonstrates the problem - is it worth filing a bug report to pinpoint what's going wrong in this particular case? Also is it a supported configuration to use commons-logging and log4j in WEB-INF/lib? I can't find a definitive statement one way or the other in the Tomcat docs, but it seems necessary to do this to get debugging info from digester etc. Unless I'm missing something. Many thanks, John. Caldarale, Charles R wrote: From: John Holman [mailto:j.g.hol...@qmul.ac.uk] Subject: commons-logging problem When packaged as a war file this combination reliably produces the exception shown below in the Tomcat console under the following circumstances: This is likely the result of a fix to prevent PermGen from filling up after some number of webapp redeployments. You can try disabling the newer behavior by setting the system property: org.apache.catalina.loader.WebappClassLoader.ENABLE_CLEAR_REFERENCES to false. Doc is here: http://tomcat.apache.org/tomcat-5.5-doc/config/systemprops.html#Other The original bug report is here: https://issues.apache.org/bugzilla/show_bug.cgi?id=41939 - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: commons-logging problem
> From: John Holman [mailto:j.g.hol...@qmul.ac.uk] > Subject: commons-logging problem > > When packaged as a war file this combination reliably produces the > exception shown below in the Tomcat console under the following > circumstances: This is likely the result of a fix to prevent PermGen from filling up after some number of webapp redeployments. You can try disabling the newer behavior by setting the system property: org.apache.catalina.loader.WebappClassLoader.ENABLE_CLEAR_REFERENCES to false. Doc is here: http://tomcat.apache.org/tomcat-5.5-doc/config/systemprops.html#Other The original bug report is here: https://issues.apache.org/bugzilla/show_bug.cgi?id=41939 - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
commons-logging problem
I have a web application running in Tomcat 5.5.27 with JDK 1.5.0_16-b02 on Windows XP SP3. log4j-1.2.15.jar and commons-logging-1.1.1.jar are installed in WEB-INF/lib and there is a context.xml file in META-INF. When packaged as a war file this combination reliably produces the exception shown below in the Tomcat console under the following circumstances: 1. deploy the war file (e.g. using Tomcat HTTP manager) 2. stop and restart tomcat 3. undeploy the war file 4. deploy the war file Note that to demonstrate this it is necessary to have both a context.xml file in META-INF and commons-logging-1.1.1.jar in WEB-INF/lib. Also, the problem disappears if you downgrade to commons-logging-1.0.4. Otherwise the contents of the application don't seem to matter - it can be demonstrated in an application containing no classes or other libraries. The only other thing I've found to have an effect is the *name* of the application. "commons-logging-test" exhibits the problem, but in at least one test renaming the same application to start with a letter later in the alphabet did not (possibly to do with the order applications are loaded)? I suspect this is a bug either in Tomcat or the logging sub-system, but these things are notoriously tricky and before reporting it as such any comments or help would be very welcome. Thanks, John. === 29-Jan-2009 21:07:43 org.apache.catalina.startup.HostConfig deployWAR INFO: Deploying web application archive commons-logging-test.war 29-Jan-2009 21:07:43 org.apache.catalina.core.StandardContext processTlds SEVERE: Error reading tld listeners java.lang.NullPointerException java.lang.NullPointerException at org.apache.log4j.Category.isEnabledFor(Category.java:749) at org.apache.commons.logging.impl.Log4JLogger.isTraceEnabled(Log4JLogg r.java:333) at org.apache.catalina.startup.TldConfig.tldScanResourcePaths(TldConfig java:581) at org.apache.catalina.startup.TldConfig.execute(TldConfig.java:282) at org.apache.catalina.core.StandardContext.processTlds(StandardContext java:4307) at org.apache.catalina.core.StandardContext.start(StandardContext.java: 144) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBas .java:760) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:7 0) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:544 at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:831 at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:51 ) at org.apache.catalina.startup.HostConfig.check(HostConfig.java:1232) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcce sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.commons.modeler.BaseModelMBean.invoke(BaseModelMBean.java 458) at com.sun.jmx.mbeanserver.DynamicMetaDataImpl.invoke(DynamicMetaDataIm l.java:213) at com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:220) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(Default BeanServerInterceptor.java:815) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:78 ) at org.apache.catalina.manager.ManagerServlet.check(ManagerServlet.java 1397) at org.apache.catalina.manager.ManagerServlet.deploy(ManagerServlet.jav :635) at org.apache.catalina.manager.ManagerServlet.doPut(ManagerServlet.java 424) at javax.servlet.http.HttpServlet.service(HttpServlet.java:650) at javax.servlet.http.HttpServlet.service(HttpServlet.java:729) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(App icationFilterChain.java:269) at org.apache.catalina.core.ApplicationFilterChain.doFilter(Application ilterChain.java:188) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapper alve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContext alve.java:172) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(Authentic torBase.java:525) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve. ava:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve. ava:117) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineVa ve.java:108) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.ja a:174) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.jav :875) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler. rocessConnection(Http11BaseProtocol.java:665) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndp int.java:528) a
