jsr369-experts@servlet-spec.java.net

[jsr369-experts] Service declarations? Was: [116-CDIRelatedBeansInServletSpec] PROPOSAL

From: Greg Wilkins <gregw_at_intalio.com>
Date: Wed, 15 Apr 2015 15:55:05 +1000

On 22 November 2014 at 13:30, Greg Wilkins <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? 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.

cheers

-- 
Greg Wilkins <gregw_at_intalio.com>  @  Webtide - *an Intalio subsidiary*
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.