https://issues.apache.org/bugzilla/show_bug.cgi?id=53619
Priority: P2
Bug ID: 53619
Assignee: dev@tomcat.apache.org
Summary: If <absolute-ordering> is defined, only fragments
mentioned in it shall get class-scanned
Severity: normal
Classification: Unclassified
Reporter: strub...@yahoo.de
Hardware: PC
Status: NEW
Version: 7.0.29
Component: Catalina
Product: Tomcat 7
There was a discussion at the dev list how one could prevent his app from
scanning all the classpath if a ServletContextInitializer is found:
http://tomcat.10.n6.nabble.com/tomcat-7-0-29-startup-time-td4984446.html
Mark pointed me at a current EG discussion:
http://java.net/jira/browse/SERVLET_SPEC-36
The agreed status seems to be that _if_ an <absolute-ordering> element exists
in WEB-INF/web.xml, then only the web-fragments mentioned therein shall be
scanned. This is especially true if the <absolute-ordering> contains no
<others/> element.
An empty <absolute-ordering/> shall therefore disable scanning at all as far as
I understood.
This seems already be reflected in servlet-3.0 section 8.2.2 "Ordering of
web.xml and web-fragment.xml" paragraph 1.d:
"If a discovered ServletContainerInitializer is loaded from an excluded jar, it
will be ignored. Excluded jars are not scanned for classes to be handled by any
ServletContainerInitializer."
What I do not yet completely understand is that servlet-3.0 section 8.2.1
"Modularity of web.xml" explicitly defines as general rule:
"As before, if the metadata-complete element is set to true in the web.xml
descriptor, annotations in the class files and web-fragments bundled in jars
will not be processed."
This not only contradicts the 'clarification' of the EG regarding the
ServletContextInitializer which is in question here, but also could be
interpreted as : "if metadata-complete is true, then no web-fragment handling
is done. Thus also no <absolute-ordering> will be evaluated".
Not that I would like this, I just like to have this clarified upfront (before
we have to throw away some work afterwards).
Did I miss something in this regard?
--
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
