On 22/09/2013 00:27, Jeremy Boynes wrote:
> If the intent of the language in the spec is to give the application
> implementation priority if it comes first in the delegation order, this
> should apply to "discovery" as well as classloading per the ServiceLoader
> semantic.
No, the intent of the language was only to make clear that the
delegation order must be honoured when loading SCI implementations.
To quote from the Servlet EG discussion on this topic:
<quote>
If the same ServletContainerInitializer is both on the container classpath
and in a jar in WEB-INF/lib, which one should be used?
Will this be by the normal inverted classloading priority
of web applications?
</quote>
The result of the discussion was "Yes." and the language was added to
the end of 8.2. It went on to discuss some edge cases but no conclusion
was reached and no further clarification was added to the spec.
> r1524727's scheme is more nuanced:
> * if orderedLibs is present, it loads and executes in the following order:
> 1) SCIs defined in the webapp's parent classloader ("container" SCIs) in
> undefined order
> 2) SCIs defined by jars in orderedLibs ("application" SCIs) in orderedLibs
> order
> * else, if the webapp loader is application first:
> 1) SCIs defined by the application classloader in undefined order
> 2) SCIs defined by the webapp's parent classloader in undefined order
> * else, as the webapp loader is parent first:
> 1) SCIs defined by the webapp's parent classloader in undefined order
> 2) SCIs defined by the application classloader in undefined order
I'll take another look at r1524727 as that isn't want was intended. What
should happen is:
- List all SCIs defined by the container
- List all SCIs defined by the application (may only be from a subset of
JARs if absolute ordering is present)
- Load all the SCIs defined by the container (note some may be loaded
from the application if the application ships with an alternative
implementation and the application first delegation model is being used)
- Load all the SCIs defined by the application
> As a concrete example of how this impacts the behaviour, consider the case
> where the application includes its own JSP engine. With the RI's delegation
> model, the application's engine's SCI would execute first allowing it to
> register a Servlet and mapping to handle the "*.jsp" pattern. When the
> container's engine's SCI was executed, that mapping would already be bound
> and could not be pre-empted (engines already need to allow for that in case
> the application configured that mapping in its web.xml). If the container is
> always given priority, then the container's engine would be used rather than
> the one the application intended.
No. It would still be loaded from the application (for that webapp).
> The spec is very clear that SCIs are intended for frameworks and not for
> general application initialization (which is covered by context listeners and
> fragment ordering).
I disagree. The specification uses adding frameworks as an example of a
use case the an SCI can support, but nowhere does it say that it may not
be used by applications or that it isn't intended for applications.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
