>>>>> On Wed, 19 Nov 2014 15:55:43 -0500 (EST), Stuart Douglas <sdouglas_at_redhat.com> 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 <gregw_at_intalio.com> 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.
Ed
--
| edward.burns_at_oracle.com | office: +1 407 458 0017