On 21/07/2013 23:07, Jeremy Boynes wrote:
> I'm confused by the spec saying: Implementations of the
> ServletContainerInitializer interface will be discovered by the
> runtime's service lookup mechanism or a container specific mechanism
> that is semantically equivalent to it. In either case,
> ServletContainerInitializer services from web fragment JAR files that
> are excluded from an absolute ordering MUST be ignored, and the order
> in which these services are discovered MUST follow the application’s
> class loading delegation model.
There was some clarification added around SCIs in Servlet 3.1 that may
or may not apply here. My responses are based on my understanding of 3.1
final.
> By "the runtime's service lookup mechanism" does it mean the
> semantics defined by java.util.ServiceLoader?
I believe it does. Note that earlier in section 8.2.4 the statement "The
ServletContainerInitializer class is looked up via the jar services
API." appears to contradict the later statement you quoted form that
same section.
I assume that ServletLoader or equivalent are acceptable. I'd suggest
opening a specification bug for clarification.
> Assuming it does, what is the meaning of "services from web fragment
> JAR files"? Is it a service where the configuration file came from a
> web fragment JAR file, or where the implementation class came from
> that location? What if the META-INF/services/SCI file is in an
> excluded JAR but the class is not, or vice versa (the ServiceLoader
> doc specifically allows for that)?
I read the following:
"The framework providing an implementation of the
ServletContainerInitializer MUST bundle in the META-INF/services
directory of the jar file a file called
javax.servlet.ServletContainerInitializer, as per the jar services API,
that points to the implementation class of the ServletContainerInitializer."
to mean that the SCI class and the definition must be in the same JAR.
The could be poor specification wording. Another specification bug
report require me thinks.
> What if the service is defined
> more than once, in at least one excluded JAR and in at least one JAR
> that is not an excluded fragment?
The specification doesn't cover that. I think there is an assumption
that it won't happen. Spec bug number 3.
> Are config files that don't come
> from web fragment jars subject to exclusion at all?
Any JAR in WEB-INF/lib without a web-fragment.xml file is processed as
if it had an empty web-fragment.xml file.
Any container provided JAR is always processed for SCIs. The
specification provides no mechanism for a web application to exclude a
container provided SCI.
> The semantics of ServiceLoader require the class to be instantiated,
> firing initializers and calling the default constructor. Those may
> have side effects. Are those meant to happen even if the service is
> excluded? IOW, is exclusion about the service or just about not
> calling onStartup()?
My reading of the section you quoted above is it is that onStartup()
must not be called. Whether or not the SCI is instantiated undefined -
i.e. either is acceptable.
> Trying to answer that, can we simplify this approach to being: 1)
> Discover all config files in delegation order by calling
> getResources("META-INF/services/SCI") on the webapp classloader 2)
> Skip all config files whose URL refers to an excluded web fragment 3)
> Parse all config files to obtain a delegation ordered set of class
> names, skipping duplicated entries 4) Instantiate all classes and
> invoke them in order
>
> Alternatively, we could use ServiceLoader itself, passing it a
> ClassLoader that did not return META-INF/services/SCI files from
> excluded web fragments - this could be a decorator only used for the
> call to discover SCIs.
Of those two options, I think I prefer the first.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
