[
https://issues.jboss.org/browse/CDI-492?page=com.atlassian.jira.plugin.sy...
]
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_...] 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)