You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2009/01/31 23:45:20 UTC

DO NOT REPLY [Bug 46645] New: commons logging issue

https://issues.apache.org/bugzilla/show_bug.cgi?id=46645

           Summary: commons logging issue
           Product: Tomcat 5
           Version: 5.5.27
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Catalina
        AssignedTo: dev@tomcat.apache.org
        ReportedBy: j.g.holman@qmul.ac.uk
                CC: j.g.holman@qmul.ac.uk


Created an attachment (id=23212)
 --> (https://issues.apache.org/bugzilla/attachment.cgi?id=23212)
Simple war file illustrating the 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, and 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)?

Note that the problem goes away if I set system property
  org.apache.catalina.loader.WebappClassLoader.ENABLE_CLEAR_REFERENCES
to false. However having had PermGen memory exhaustion problems in the past I
am loathe to do this, and would also prefer to work Tomcat in its default
configuration as far as possible.

Simple war file attached in the hope that this will help pinpoint the problem.

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)
        at
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFo
lowerWorkerThread.java:81)
        at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(Thread
ool.java:689)
        at java.lang.Thread.run(Thread.java:595)


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org


DO NOT REPLY [Bug 46645] commons logging issue

Posted by bu...@apache.org.
https://issues.apache.org/bugzilla/show_bug.cgi?id=46645


Mark Thomas <ma...@apache.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID




--- Comment #1 from Mark Thomas <ma...@apache.org>  2009-01-31 17:39:17 PST ---
org.apache.catalina.loader.WebappClassLoader.ENABLE_CLEAR_REFERENCES=true (the
default) is provided to work around memory leak issues in applications and
third party libraries. While well written code shouldn't need it, experience
has shown that it fixes more issues than it creates - hence the default.

The down side of this feature is that it can cause issues since it nulls out
various internal fields and code may well react badly to this.

It should be safe to set this to false providing your app and the libraries you
use don't leak memory. You can always check this with a profiler.


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org