2012/5/12 Jesse Farinacci <jie...@gmail.com>: > Greetings, > > On Fri, May 11, 2012 at 8:47 PM, Konstantin Kolinko > <knst.koli...@gmail.com> wrote: >> I can easily reproduce this "zip file closed" issue in trunk with a >> simple jar containing Tomcat's icon in META-INF/resources/favicon.ico >> if I change configuration by removing JreMemoryLeakPreventionListener >> from server.xml. >> The first request to <appname>/favicon.ico hits the error. > > Thank you for reproducing the problem. I confirm that my Apache Tomcat > instance was not running with that listener. I've now set: > > <Listener className="org.apache.catalina.core.AprLifecycleListener"/> > <Listener className="org.apache.catalina.core.JasperListener"/> > <Listener > className="org.apache.catalina.core.JreMemoryLeakPreventionListener" > /> > <Listener > className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" > /> > <Listener > className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener"/> > <Listener className="org.apache.catalina.security.SecurityListener" /> > >> It is a rare configuration and IMHO a broken one. >> I think that running without JreMemoryLeakPreventionListener is wrong. > > Here I must object. Yes, it probably is rare, but running without > those extra listeners isn't wrong.
They are there for a reason. You would experience a number of other issues during webapp undeploy/reload if you do not have that listener configured. > I have a web application with a > valid library in WEB-INF/lib which ships a specification supported > static resource. That resource is not being served by Apache Tomcat > unless I enable a non-standard (specification wise) option. That > doesn't seem right to me.. > Well, if you remove "JasperListener", you wouldn't be able to serve JSPs. If you change conf/web.xml you may break some specification-dictated defaults (such as the default list of welcome files, or jsp support). If you do not explicitly set "o.a.c.STRICT_SERVLET_COMPLIANCE" system property to the value of "true" you are not adhering to the spec either. There are many ways to break things. >> I cannot reproduce the issue with the standard configuration. > > With the listeners all added, things are working as I expect. The > resource is served, no error is produced. I still think this is a bug > though.. if I open a new bug, will it be accepted? > I do not know. If there exists a simple solution (like reopening the closed jar in WARDirContext?) then it is worth trying. If there is not, then I see little wrong with resolving it as WONTFIX and asking people to have proper configuration, but I will leave it to others for a while to take another look and decide. As with enhancement requests, if there is a patch, or if there is wide interest in it (other ways to trigger it?), the more are its chances. I personally have some grudge against WebappClassLoader.closeJARs() [2] and maybe disabling it will workaround the issue (not tested) but I do not know what actually happens here at the moment. [2] https://issues.apache.org/bugzilla/show_bug.cgi?id=52448 Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
