[cdi-dev] [JBoss JIRA] (CDI-492) Give ownership of servlet specific part to servlet specification

[Ed Burns (JIRA)]

    [ https://issues.jboss.org/browse/CDI-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022101#comment-13022101 ] 

Ed Burns commented on CDI-492:
------------------------------

I brought up this issue in the servlet EG and it was shot down.  Here is the reasoning.  As spec lead, I do agree with the reasoning so I have provisionally closed the issue unless we can find a way to address the concerns of the servlet EG:

{quote}
>>>>> On Wed, 19 Nov 2014 15:55:43 -0500 (EST), Stuart Douglas said:

[...]

SD> I think however there may be some backwards compatibility issues for
SD> the standalone servlet container case.

SD> Say I have an application that packages Weld (or OWB) that I have
SD> deployed on a Servlet 3.1 container, and I now want to move it to a
SD> Servlet 4.0 container. The older version of Weld will still provide
SD> the HttpServletRequest beans (as it is required to do by spec) and
SD> the servlet container will also provide these beans (as we are
SD> required to do by spec) and as a result if you try and inject them
SD> you will get a bean resolution error as two beans resolve to the
SD> injection point.

SD> This also works in reverse, if you deploy a new version of CDI to an
SD> older servlet container then no beans will be registered, however I
SD> think this is less of an issue.

SD> For servers that don't actually provide CDI API jars there may also
SD> be some linking issues. The producers need to be linked against the
SD> CDI API which in this case will be provided by the deployment, so it
SD> won't really be possible to just have them as a global library.

>>>>> On Fri, 21 Nov 2014 14:06:24 +1100, Greg Wilkins said:
[...]

GW> I share Stuarts concerns about classloading confusion. More over,
GW> I'm concerned that by making CDI to servlet mapping a responsibility
GW> of the servlet container, then we are going to have to do a
GW> container to CDI adaptation for every CDI implementation out there.

GW> The servlet specification already provides servlet container initializers,
GW> which have all the power required for CDI implementations to implement
GW> these CDI v Servlet cross concerns. 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. I will provisionally close this issue for
now at least.
{quote}

> Give ownership of servlet specific part to servlet specification
> ----------------------------------------------------------------
>
>                 Key: CDI-492
>                 URL: https://issues.jboss.org/browse/CDI-492
>             Project: CDI Specification Issues
>          Issue Type: Feature Request
>          Components: Java EE integration
>            Reporter: Antoine Sabot-Durand
>
> [Section 3.8 of the spec|http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#additional_builtin_beans] 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,
> {quote}
> A servlet container must provide the following built-in beans, all of which have qualifier @Default:
> * a bean with bean type {{javax.servlet.http.HttpServletRequest}}, allowing injection of a reference to the HttpServletRequest
> * a bean with bean type {{javax.servlet.http.HttpSession}}, allowing injection of a reference to the HttpSession,
> * a bean with bean type {{javax.servlet.ServletContext}}, allowing injection of a reference to the ServletContext,
> These beans are passivation capable dependencies, as defined in Passivation capable dependencies.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.8#6338)