Arjan,
So if servlet containers provide a portable API for CDI customisation, and
CDI provides a portable API for Servlet container customisation, then we
have a coin toss as to who should take on the responsibility for specifying
and implementing the CDI+Servlets behaviour.
I can see why both groups would rather the other take on that
responsibility/burden.
So perhaps it is an EE architectural decision to determine on whose
shoulders the other should stand. If it turns out that servlets and CDI
are true siblings and that neither is dependent on the other, then perhaps
the EE architects can come up with a convention for how such sibling
interaction can be specified - perhaps as a separate JSR?
Note that there may even be scope for both approaches to be used. When
deploying CDI as part of a webapplication, then it is version independent
from the servlet container and any CDI classes known to the container
should be hidden from the CDI within the web application. In such a
deployment mode, it perhaps should be the CDI impl that makes use of the
portable servlet APIs for discovery of classes and annotations that is must
inject.
When deploying CDI as a container provided service, then perhaps the
container can use portable APIs provided by CDI implementations to
implement the behaviour. In such circumstances, a container may even
choose to only work with one CDI implementation and use none portable
APIs. In this mode, the user loses the ability to pick and choose their
CDI implementation and version (which may not be a bad thing).
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 ]
cheers
On 22 November 2014 02:32, arjan tijms <arjan.tijms_at_gmail.com> wrote:
> Hi,
>
> On Fri, Nov 21, 2014 at 4:09 PM, Edward Burns <edward.burns_at_oracle.com>
> wrote:
> >>>>>> On Wed, 19 Nov 2014 15:55:43 -0500 (EST), Stuart Douglas <
> sdouglas_at_redhat.com> said:
> > GW> Thus I think these things must
> > GW> remain a CDI impl responsibility as they are able to write container
> > GW> portable code that will handle these concerns. The inverse is not
> true if
> > GW> we make them container concerns.
> >
> > Excellent points. I will use these to push back on
> > CDI-492-FobStuffToServlet.
>
> IMHO, unless I'm missing something here, but the assertion made above
> is not correct. It's not only CDI that can write container portable
> code.
>
> As mentioned in the other reply, the extension and producer mechanisms
> needed are portable, public and non CDI-implementation specific. Every
> Servlet container can use these mechanisms to produce the required
> artefacts, without needing any CDI implementation specific code.
>
> So pushing back on this on the basis of (or just including the fact
> that) Servlet containers needing to resort to non-portable code, which
> I think is Greg's main concern, would not be entirely valid.
>
> Arjan Tijms
>
>
>
>
>
>
> I will provisionally close this issue for
> > now at least.
> >
> > Ed
> >
> > --
> > | edward.burns_at_oracle.com | office: +1 407 458 0017
>
--
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.