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.
By "the runtime's service lookup mechanism" does it mean the semantics defined
by java.util.ServiceLoader?
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)?
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?
Are config files that don't come from web fragment jars subject to exclusion at
all?
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()?
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
