DO NOT REPLY [Bug 49218] Fix support for META-INF/resources
https://issues.apache.org/bugzilla/show_bug.cgi?id=49218 Mark Thomas ma...@apache.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #7 from Mark Thomas ma...@apache.org 2010-05-12 07:10:21 EDT --- The remaining issue has been fixed in trunk and will be included in 7.0.0 onwards. -- 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49218] Fix support for META-INF/resources
https://issues.apache.org/bugzilla/show_bug.cgi?id=49218 --- Comment #6 from Peter Rossbach p...@objektpark.de 2010-05-03 05:48:36 EDT --- (In reply to comment #5) (In reply to comment #4) TestStandardContextResources calling resourceF.jsp in r939650 checks for wrong value. It should look for resourceF.jsp in resources.jar. Fix with 940405. Sorry! Besides that, it really uncovered a bug. The test fails because of the following: 5. In BaseDirContext#lookup(): altDirContext.lookup(META-INF/resources/ + name) does not return null, but throws a NamingException, which aborts the for( : altDirContexts) cycle. Ok, look at listBindings. We can ignore the sub Exceptions. Fixed! So, either lookup for resourceF.jsp or for resourceF.jsp will fail, depending on the order in altDirContexts (the spec says that the order is arbitrary). 6. Also in BaseDirContext#lookup(): doLookup(name) call is also documented to throw NamingException. Either it does not throw it and the doLookup method signature has to be updated (or at least add a JavaDoc there), or the code is broken. +1 .. Go ahead to fix doLookup(name)! -- 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49218] Fix support for META-INF/resources
https://issues.apache.org/bugzilla/show_bug.cgi?id=49218 --- Comment #5 from Konstantin Kolinko knst.koli...@gmail.com 2010-05-01 08:13:02 EDT --- (In reply to comment #4) TestStandardContextResources calling resourceF.jsp in r939650 checks for wrong value. It should look for resourceF.jsp in resources.jar. Besides that, it really uncovered a bug. The test fails because of the following: 5. In BaseDirContext#lookup(): altDirContext.lookup(META-INF/resources/ + name) does not return null, but throws a NamingException, which aborts the for( : altDirContexts) cycle. So, either lookup for resourceF.jsp or for resourceF.jsp will fail, depending on the order in altDirContexts (the spec says that the order is arbitrary). 6. Also in BaseDirContext#lookup(): doLookup(name) call is also documented to throw NamingException. Either it does not throw it and the doLookup method signature has to be updated (or at least add a JavaDoc there), or the code is broken. -- 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49218] Fix support for META-INF/resources
https://issues.apache.org/bugzilla/show_bug.cgi?id=49218 --- Comment #2 from Peter Rossbach p...@objektpark.de 2010-04-30 07:44:34 EDT --- Created an attachment (id=25384) -- (https://issues.apache.org/bugzilla/attachment.cgi?id=25384) Not found Resource Example with to fragments -- 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49218] Fix support for META-INF/resources
https://issues.apache.org/bugzilla/show_bug.cgi?id=49218 --- Comment #3 from Peter Rossbach p...@objektpark.de 2010-04-30 07:53:40 EDT --- I have build a standalone war that still have the not found problem! Arrg! I have build two fragments: servlet30/WEB-INF/lib/hello2.jar META-INF/ META-INF/MANIFEST.MF api/ api/HelloApiServlet.class api/ServletSetupListener.class META-INF/resources/ META-INF/resources/A/ META-INF/resources/A/resourceB.jsp META-INF/resources/hello.jsp META-INF/resources/hello.txt META-INF/resources/resourceB.jsp META-INF/web-fragment.xml !-- has an order constraint deployed after other-fragment -- and other.jar META-INF/ META-INF/MANIFEST.MF annotation/ annotation/GetResourceServlet.class META-INF/resources/ META-INF/resources/folder/ META-INF/resources/folder/resourceC.jsp META-INF/resources/folder/resourceD.jsp META-INF/resources/resourceA.jsp META-INF/resources/resourceB.jsp META-INF/web-fragment.xml dir: daVinci:servlet30 peter$ tree * META-INF |-- MANIFEST.MF `-- context.xml WEB-INF |-- classes | |-- annotation | | |-- GetResourceServlet.class | | |-- HelloBean.class | | |-- HelloFilter.class | | |-- HelloServlet.class | | |-- LogApplicationLifeCycleListener.class | | |-- LogRequestListener.class | | `-- ParamServlet.class | `-- api |-- lib | |-- hello2.jar | `-- over.jar `-- web.xml folder |-- resourceC.jsp `-- resourceE.jsp index.jsp resourceA.jsp I can't access hello.jsp or hello.txt, but can access resourceB.jsp... Very strange! -- 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49218] Fix support for META-INF/resources
https://issues.apache.org/bugzilla/show_bug.cgi?id=49218 --- Comment #4 from Peter Rossbach p...@objektpark.de 2010-04-30 08:12:09 EDT --- Have checkin second resource2.jar and update testcase TestStandardContextResources to failed again! Sorry... -- 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 49218] Fix support for META-INF/resources
https://issues.apache.org/bugzilla/show_bug.cgi?id=49218 --- Comment #1 from Konstantin Kolinko knst.koli...@gmail.com 2010-04-29 23:45:59 EDT --- Re: zip file closed Thanks to Peter Roßbach, I found that webapp-3.0-fragments webapp fails only when it is run in a testcase. If it is deployed on a standalone Tomcat 7 instance, it works. After some thought I found the cause: the test runs successfully if I add JreMemoryLeakPreventionListener to the configuration. It sounds a bit weird, but so it is. My speculation is that we somewhere close the JarFile/ZipFile explicitly. The system-wide caching, that is turned off by JreMemoryLeakPreventionListener, caches a JarFile when it is accessed through URL. Explicitly closing the file closes the file in the cache, making it unusable. I debugged it a bit, and the place where the JAR is closed is WebappClassLoader#closeJARs() that is called as soon as web application startup is completed. As of now, I resolve this by adding JreMemoryLeakPreventionListener to the testcase configuration. Are there other ways to resolve this, e.g. to somehow change how the resource JARs are handled? -- 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
