Am 10.05.2017 um 19:59 schrieb Mark Thomas:
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
Thanks Mark for your quick answers!
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
