On 15/04/2015 00:55, Greg Wilkins wrote:
>
> On 22 November 2014 at 13:30, Greg Wilkins <gregw_at_intalio.com
> <mailto:gregw_at_intalio.com>> wrote:
>
> Of course we will then have the problem of webapps with their own
> CDI being deployed on containers that provide CDI - then boom! game
> over! It is almost as if we need a webapp to be able to declare
> what services it wants the container to provide - ie every webapp
> can declare it's own profile.... but are we then re-inventing
> OSGi? [NB. I blame xerces for this mess.... it started the trend
> of webapps depending on implementations rather than APIs ]
>
>
> Currently jetty has a proprietary and somewhat clunky mechanism for
> determining what services to expose to what contexts within a server.
> Jetty has always done this with most services like JSP, JAAS, JNDI, JMX,
> which we treat as optional, but are often available by default in other
> containers.
>
> With the introduction of other services such as CDI, JSR356 websockets
> and with existing services increasingly using
> ServletContainerInitializers then we are increasingly having to expose
> the configuration of these services to our users.
>
> Is there any interest in coming up with something in Servlet 4.0 to
> standardise the availability of services on a per context basis?
Yes.
> Something like (and this is a though bubble more than a concrete proposal):
>
> <Services>
> <include>javax.websocket</include>
> <include>javax.enterprise.inject</include>
> <exclude>javax.jsp</exclude>
> </Services>
>
> which would supt the containers classpath and initialise a WebSocket
> container within the context, initialise container provided CDI and
> exclude JSP so that there would be no scanning for TLDs etc. wasting the
> contexts time. It could also be used to control the ordering of
> ServletContainerInitializers as we already have the problem of websocket
> vs CDI ordering. Any services not explicitly included or excluded
> could be left to their container defaults as they are today.
>
> We definitely need something like this in Jetty, but it would be better
> if there was at least a smear of standardisation over it. So if there
> is any interest, then we might work up a better proposal and some more
> concrete examples.
Tomcat has a similar requirement. We took the approach of enabling web
applications to filter the container provided SCIs that were processed
on a per web application basis.
For this proposal to work we need to way to map from the service
identifier (e.g. javax.enterprise.inject above) to an implementation so,
for example, if someone drops a CDI implementation into Tomcat's shared
libraries (to make it available to all webapps) then Tomcat is able to
figure out that that JAR is a CDI implementation and that the SCI should
be skipped if a web application has declared
<exclude>javax.enterprise.inject</exclude>. I've only been thinking
about this for as long as it took me to type this paragraph but I don't
see any easy way to do this yet.
My instinct is that this feature needs to be tied to SCIs somehow.
Mark