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>
> To: 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 | office: +1 407 458 0017
>