Community
Participate
Working Groups
Created attachment 168545 [details] Patch to include JarScanner in customized Context for Tomcat 7 The "Serve Modules Without Publishing" option for Tomcat 7 servers fails support certain Servlet 3.0 features for Web Fragment Projects. Currently with this option enabled, Tomcat 7 will fail to discover the "META-INF/web-fragment.xml" file as well as a "META-INF/services/javax.servlet.ServletContainerInitializer" file, which declares a ServletContainerInitializer. Fortunately, Tomcat 7 provides a simple way to address this. Contexts can specify a JarScanner with the scanAllDirectories attribute set true. This will cause directories on the web application's classpath to be checked as if they were expanded jars. The attached patch makes use of this feature. Unfortunately, there is currently a bug in Tomcat 7 that will cause it to fail to start if this feature is used. I've entered https://bugs.eclipse.org/bugs/show_bug.cgi?id=311079 in the Apache Bugzilla to report this problem. If it happens to get fixed in time, I hope to include this patch in WTP 3.2RC2, or possibly WTP 3.2RC3. If not fixed in time, we'll have to save this for WTP 3.2.1.
Angel, The necessary changes to Tomcat 7 have been applied for Tomcat bug https://issues.apache.org/bugzilla/show_bug.cgi?id=49290 (somehow I pasted the wrong link above), so I would like to request this bug for PMC review for RC2, if you agree. Here are the required details: * Explain why you believe this is a stop-ship defect. For Web Fragment Projects, the "META-INF/web-fragment.xml" file, and if present, a "META-INF/services/javax.servlet.ServletContainerInitializer" file will not be processed when the "Serve Modules Without Publishing" option is enabled. Unless the web-fragment.xml file is essentially empty and the "javax.servlet.ServletContainerInitializer" file is not present, then the Web Fragment project will lose important Servlet 3.0 behavior when this option is enabled. * Is there a work-around? If so, why do you believe the work-around is insufficient? No work-around to get these Servlet 3.0 features working with this option enabled. * How has the fix been tested? Is there a test case attached to the bugzilla record? Has a JUnit Test been added? I have verified the fix to Tomcat 7 for has been applied and have built a local copy of Tomcat 7 for testing. I've manually tested the WTP fix and verified that has the desired effect on the server configuration and that Tomcat starts successfully thanks to the fix that was applied. A servlet mapping in a web-fragment.xml was functional and a ServletContainerInitializer was successfully called. No JUnit has been implemented. * Give a brief technical overview. Who has reviewed this fix? The mechanism by which Tomcat 7 detects and processes "web-fragment.xml" and "javax.servlet.ServletContainerInitializer" files in jars doesn't work with the current abilities of the "Serve Modules Without Publishing" option. Fortunately, Tomcat 7 provides a new feature where you can request that directories on the web application classpath be checked as if they were expanded jars. This patch enables that feature for Tomcat 7 servers. * What is the risk associated with this fix? Minimal. The changes affects only an isolated feature of the Tomcat server adapter, and alters behavior in a limited code path.
This changes affect only tomcat 7 and only the "Serve Modules Without Publishing" feature. Getting this changes into the build will make the support of tomcat 7 and servlet 3.0 more solid, by the time that WTP 3.2 releases.
Adding PMC to Whiteboard so this bug shows up in the review list.
I think it is good to make this support more solid, and appears low risk. Thank you.
Changes released to HEAD.
Verified "META-INF/web-fragment.xml" and "META-INF/services/javax.servlet.ServletContainerInitializer" are being picked up using WTP S-3.2.0RC2-20100520232028 build.
Closing.
New Gerrit change created: https://git.eclipse.org/r/108958
