[cdi-dev] Moving on SERVLET_SPEC-116 (giving servlet beans to servlet spec)
john.ament at spartasystems.com
Wed Oct 12 06:53:29 EDT 2016
Definitely a good idea. I also reached out to Ed/Servlet EG recently about CDI-452. If we can schedule this meeting, I'd like to include 452 on the topic to make sure there's no crossed wires (I haven't read the full response yet, but I suspect there will still be questions).
From: cdi-dev-bounces at lists.jboss.org <cdi-dev-bounces at lists.jboss.org> on behalf of Antoine Sabot-Durand <antoine at sabot-durand.net>
Sent: Wednesday, October 12, 2016 4:43 AM
Cc: edward.burns at oracle.com
Subject: [cdi-dev] Moving on SERVLET_SPEC-116 (giving servlet beans to servlet spec)
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?
---------- Forwarded message ----------
From: Antoine Sabot-Durand <asd at redhat.com<mailto: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<mailto:edward.burns at oracle.com>>
Cc: Shing Wai Chan <shing.wai.chan at oracle.com<mailto:shing.wai.chan at oracle.com>>
Glad to ear that. as you can check on our side  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
On Tue, Oct 11, 2016 at 5:26 PM, Edward Burns <edward.burns at oracle.com<mailto:edward.burns at oracle.com>> wrote:
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  . We ended up resolving SERVLET_SPEC_116 as
WORKS_AS_DESIGNED for this reason, the "classloader and backward
>>>>> On Wed, 19 Nov 2014 15:55:43 -0500 (EST), Stuart Douglas <sdouglas at redhat.com<mailto: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<mailto: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<mailto: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?
| edward.burns at oracle.com<mailto:edward.burns at oracle.com> | office: +1 407 458 0017<tel:%2B1%20407%20458%200017>
NOTICE: This e-mail message and any attachments may contain confidential, proprietary, and/or privileged information which should be treated accordingly. If you are not the intended recipient, please notify the sender immediately by return e-mail, delete this message, and destroy all physical and electronic copies. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cdi-dev