On Sep 20, 2013, at 8:50 AM, Mark Thomas <ma...@apache.org> wrote: > On 20/09/2013 16:02, Jeremy Boynes wrote: >> The only ordering concern for SCIs in the spec is that they are >> "discovered" following the classloader delegation model. This will >> typically be configured to load application classes first, >> something r1524727 does not do. > > The intention of the language around discovery is to clarify the > expected behaviour when both the container and the application provide > an implementation of the same SCI. As with any other class, the > delegation model adopted by the application must be used. > > It has no bearing on the order in which one SCI implementation is > loaded with respect to another SCI.
Thinking more here, the spec refers to the "service lookup mechanism" which
we've taken as being java.util.ServiceLoader. The semantics of that, returning
services using an Iterator<S>, means services must be loaded and instantiated
to return them. ServiceLoader consistently returns services in instantiation
order. That has bearing as it determines the order in which class initializers
and constructors are called.
> It has no bearing on the order in which one SCI implementation is
> invoked with respect to another SCI.
Given "discovery" and loading is ordered, I think it's reasonable for instances
to be invoked in the same order.
> r1524727 is fully compliant with the Servlet spec.
Perhaps with the letter but it seems at odds with the intent. If frameworks
with SCIs are to be treated in the same way as other extensions they should
follow the classloader delegation model with container supplied versions
prioritized before *or after* application supplied versions per that model.
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. As
noted in JIRA[1] for the reference implementation, GlassFish loads *and
executes* SCIs in the order they are "discovered" by ServiceLoader, following
the priority of the delegation model.
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
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.
This example can be applied equally to any WebSocket, JAX-WS or JAX-RS
framework that is provided by both an application and the container. That's
especially important for the hosted case where applications may require a
specific implementation of a framework be used and where they would not be able
to modify those provided by the container.
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).
This basically comes down the the following sequence for initialization:
1) load and merge web.xml and all web-fragment.xml, applying fragment ordering
2) load and invoke framework SCIs in delegation order so they can add to the
effective web.xml
3) add configuration from container's default web.xml
4) initialize application by calling SCLs in web.xml order (they may in turn
add servlets and filters)
5) initialize servlets and filters in load-on-startup order
Cheers
Jeremy
[1] https://java.net/jira/browse/GLASSFISH-20788
signature.asc
Description: Message signed with OpenPGP using GPGMail
