On 10/05/17 12:40, Michael Heinen wrote: > Am 10.05.2017 um 12:18 schrieb Mark Thomas: >> On 10/05/17 10:26, Michael Heinen wrote: >>> Am 10.05.2017 um 00:40 schrieb Mark Thomas: >>>> On 09/05/17 15:25, Michael Heinen wrote: >>>>> Hi all, >>>>> >>>>> I am currently mirgating an application from Tomcat 7.0.73 to 8.0.43. >>>>> On development platforms we use an embedded tomcat. >>>>> On of the jars on the classpath contains a web-fragment.xml in it's >>>>> META-INF folder. >>>>> This jar file is NOT located within the webApp but simply on the >>>>> classpath. >>>>> With Tomcat 7.0.73 the web-fragment is processed and the defined >>>>> filter >>>>> is instantiated. >>>>> With Tomcat 8.0.43 the web-fragment is not processed at all.
<snip/> >>> Should I open a bug? >> Maybe. There might be a (spec related) reason for that. E.g. Something >> that was tightened up / clarified in Servlet 3.1 that wasn't back-ported >> to Tomcat 7 in case users were relying on the functionality. >> >> The next thing to check is the svn history for those files. >> https://svn.apache.org/viewvc/tomcat/ and the annotate (a.k.a blame) >> view is useful for that. The key is likely to be the commit that added >> the isWebapp test. >> >> Mark > > I digged into the history an found following changeset with the comment > "Container provided JARs should not be scanned for deployment > annotations nor should they be checked for web-fragment.xml files." > https://svn.apache.org/viewvc?view=revision&revision=1493066 > I have no idea how to find the corresponding ticket but a guy called > "markt" implemented this ;-) If there was an associated Bugzilla issue, a link to it would normally be included in the commit message. > So the check has been added on purpose but I don't know the reason for > that. > What next? Let me look at the specs and see if there was a change/clarification that might have prompted this. I do recall in that timeframe that there were some clarifications about what got scanned in what circumstances. /me goes to read spec docs... The relevant language is in section 8.2.1 <quote> only JAR files bundled in a web application's WEB-INF/lib directory, but not those higher up in the class loading delegation chain, need to be scanned for web-fragment.xml </quote> Therefore, Tomcat 8.0 looks to be doing the right thing. Digging into the archives, finds this thread: http://tomcat.markmail.org/thread/z3n2lfaa6zlpvodl It looks like this was missed when we implemented Servlet 3.0 (Tomcat 7) but was picked up during the 3.1 work. I haven't looked at the changes in detail but it looks like some combination of needing the new scanning API to implement it and not wanting to change 7.0.x behaviour after several years of stable releases was responsible for it not being back-ported. Neither web-fragment.xml change nor the wider JarScanner changes are listed in the 7.0.x to 8.0.x migration guide. That looks like it should be corrected. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
