[cdi-dev] Moving on SERVLET_SPEC-116 (giving servlet beans to servlet spec)
Antoine Sabot-Durand
antoine at sabot-durand.net
Wed Oct 12 04:43:05 EDT 2016
Hi All,
Ed burns (in cc) contacted me yesterday to follow our brief encounter at
Java One to re-open SERVLET_SPEC-116 (CDI-492 on our side).
As you can see in the discussion below, I gave some leads to solve their
issues and suggested that we help them to work on them.
Perhaps we could start by setting up an online meeting with all interested
person on both EG?
Antoine
---------- Forwarded message ----------
From: *Antoine Sabot-Durand* <asd at redhat.com>
Date: Wed, Oct 12, 2016 at 10:22 AM
Subject: Re:
[SERVLET_SPEC-116-CDIRelatedBeansInServletSpec][CDI-492-FobStuffToServlet]
Revitalization attempt
To: Edward Burns <edward.burns at oracle.com>
Cc: Shing Wai Chan <shing.wai.chan at oracle.com>
Hi Ed,
Glad to ear that. as you can check on our side [1] we are ready to help you
solve these point
Solutions are reachable:
For the backward compatibility issue raised by Stuart:
As I already said, the backward compatibility could be solved by either a
qualifier or by adding to CDI an easy way to detect its version and decide
of the bean creation on servlet side according to it.
For the portable implementation issue:
I don't understand what is the problem here. CDI provide a powerful SPI
that allows development of portable extensions. Unless I miss something, I
see no reason why this code shouldn't be developed at the spec level and so
being portable. BTW we are of course ready to help you right this code.
For the class loading issue:
2 solutions here:
- accept to have an inactive class in your implementation (a CDI portable
extension) linked to a missing library (cdi-api). As it will never be
called no error should be raised
- do like JAX-RS by creating a specific jar for CDI support in your
implementation. The jar would be included in Java EE and not in Servlet
only server
That's only from my understanding and knowledge of the problem, if we go to
a discussion with all CDI EG, we may find even more better solutions.
I suggest that start a workgroup including member of the EG on both side to
work on this issues resolution
Wdyt?
Antoine
[1]
http://cdi-development-mailing-list.1064426.n5.nabble.com/Which-version-of-HttpServletRequest-is-injected-td5713578.html#a5713688
On Tue, Oct 11, 2016 at 5:26 PM, Edward Burns <edward.burns at oracle.com>
wrote:
Hello Antoine,
When I briefly bumped into you at JavaOne, you expressed a desire to
revisit this issue. Since we didn't make time to meet at JavaOne, I am
following up over email.
Way back at the beginning of Servlet 4.0, I attempted to get this one
resolved. We filed two JIRAS, as in the subject, and had some
discussion [1] [2]. We ended up resolving SERVLET_SPEC_116 as
WORKS_AS_DESIGNED for this reason, the "classloader and backward
compatibility concern":
>>>>> On Wed, 19 Nov 2014 15:55:43 -0500 (EST), Stuart Douglas <
sdouglas at redhat.com> said:
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.
>>>>> On Fri, 21 Nov 2014 14:06:24 +1100, Greg Wilkins <gregw at intalio.com>
said:
GW> While initially I thought that the words "when running in an
GW> environment that also supports CDI..." would be sufficient to make
GW> this OK, I'm now doubting that. I share Stuarts concerns about
GW> classloading confusion.
>>>>> On Fri, 21 Nov 2014 07:03:33 -0800, Edward Burns <
edward.burns at oracle.com> said:
EB> Ajran, while your observations are accurate, the backward
EB> compatibility issues raised by Stuart and seconded by Greg are
EB> showstoppers for this change in my opinion at this point.
There was an additional concern, the "portable implementation concern":
it is not possible to provide portable implementations of the code
necessary to implement the new requirements that would be in the Servlet
spec, taken from CDI section 3.8:
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.
In my understanding, the portable implementation concern has been adequately
addressed by API in CDI 2.0. Is that correct?
Do you have any suggestion for how to address the classloader and
backward compatibility concern?
Thanks,
Ed
--
| edward.burns at oracle.com | office: +1 407 458 0017
[1]
https://java.net/projects/servlet-spec/lists/jsr369-experts/archive/2014-11/message/1
[2]
https://java.net/projects/servlet-spec/lists/users/archive/2014-11/message/26
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20161012/b71d71fc/attachment-0001.html
More information about the cdi-dev
mailing list