On 21/11/2014 03:06, Greg Wilkins wrote:
>
> Ed,
>
> While initially I thought that the words "when running in an environment
> that also supports
> CDI..." would be sufficient to make this OK, I'm now doubting that.
> I share Stuarts concerns about classloading confusion.
> More over, I'm concerned that by making CDI to servlet mapping a
> responsibility of the servlet container, then we are going to have to do
> a container to CDI adaptation for every CDI implementation out there.
>
> The servlet specification already provides servlet container
> initializers, which have all the power required for CDI implementations
> to implement these CDI v Servlet cross concerns. Thus I think these
> things must remain a CDI impl responsibility as they are able to write
> container portable code that will handle these concerns. The inverse is
> not true if we make them container concerns.
+1
Greg and Stuart have articulated (better than I could) my concerns as well.
I'll add that if there are API changes we could make that would make
implementation of these cross-spec concerns easier for CDI implementers
then I'm open to suggestions.
Mark
>
> regards
>
>
>
>
> On 20 November 2014 07:55, Stuart Douglas <sdouglas_at_redhat.com
> <mailto:sdouglas_at_redhat.com>> wrote:
>
> I think this sounds good in theory, although as a full EE app server
> we are always going to have CDI support available, so it does not
> make much (any) difference to us if it is provided by the Servlet or
> the CDI implementation.
>
> I think however there may be some backwards compatibility issues for
> the standalone servlet container case.
>
> Say I have an application that packages Weld (or OWB) that I have
> deployed on a Servlet 3.1 container, and I now want to move it to a
> Servlet 4.0 container. The older version of Weld will still provide
> the HttpServletRequest beans (as it is required to do by spec) and
> the servlet container will also provide these beans (as we are
> required to do by spec) and as a result if you try and inject them
> you will get a bean resolution error as two beans resolve to the
> injection point.
>
> This also works in reverse, if you deploy a new version of CDI to an
> older servlet container then no beans will be registered, however I
> think this is less of an issue.
>
> For servers that don't actually provide CDI API jars there may also
> be some linking issues. The producers need to be linked against the
> CDI API which in this case will be provided by the deployment, so it
> won't really be possible to just have them as a global library.
>
> Stuart
>
> ----- Original Message -----
> > From: "Edward Burns" <edward.burns_at_oracle.com
> <mailto:edward.burns_at_oracle.com>>
> > To: jsr369-experts_at_servlet-spec.java.net
> <mailto:jsr369-experts_at_servlet-spec.java.net>
> > Sent: Thursday, 20 November, 2014 5:09:51 AM
> > Subject: [jsr369-experts] [116-CDIRelatedBeansInServletSpec] PROPOSAL
> >
> > Hello Volunteers,
> >
> > The Servlet spec PDF currently only mentions CDI on two pages (and one
> > of them is a reference to the other). It appears the normative
> > declaration of the requirements in Servlet regarding CDI is in our
> > section 15.5.15 "Contexts and Dependency Injection for Java EE
> > requirements".
> >
> > The CDI spec is trying to trim itself down and part of that effort
> > requires fobbing off some requirements previously declared in the CDI
> > spec itself to other related specs. In this case, we have the
> > following:
> >
> > CDI Spec section 3.8 [1] places some requirements on CDI
> implementations
> > when running with Servlet. To better suit user desires for modularity
> > these requirements are better met by moving them to the Servlet
> > spec. Specifically,
> >
> > CDI3.8> A servlet container must provide the following built-in
> > CDI3.8> beans, all of which have qualifier @Default:
> >
> > CDI3.8> a bean with bean type
> javax.servlet.http.HttpServletRequest,
> > CDI3.8> allowing injection of a reference to the HttpServletRequest
> >
> > CDI3.8> a bean with bean type javax.servlet.http.HttpSession,
> > CDI3.8> allowing injection of a reference to the HttpSession,
> >
> > CDI3.8> a bean with bean type javax.servlet.ServletContext,
> allowing
> > CDI3.8> injection of a reference to the ServletContext,
> >
> > CDI3.8> These beans are passivation capable dependencies, as
> defined
> > CDI3.8> in Passivation capable dependencies.
> >
> > To put these items in the Servlet spec, we may have to couch them in
> > terms similar to, "when running in an environment that also supports
> > CDI...".
> >
> > PROPOSAL:
> >
> > Include language in our spec section 15.5.15 which allows the CDI spec
> > to remove their language while preserving desired existing user
> > functionality.
> >
> > What do you all think? I know several of our constituents do not
> count
> > CDI support among their user requirements. Is this going to be a
> > problem?
> >
> > Ed
> >
> > [1]
> http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#additional_builtin_beans
> >
> > --
> > | edward.burns_at_oracle.com <mailto:edward.burns_at_oracle.com> |
> office: +1 407 458 0017 <tel:%2B1%20407%20458%200017>
> >
>
>
>
>
> --
> Greg Wilkins <gregw_at_intalio.com <mailto: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.