Antoine, 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). John ________________________________ From: cdi-dev-bounces(a)lists.jboss.org <cdi-dev-bounces(a)lists.jboss.org&gt; on behalf of Antoine Sabot-Durand <antoine(a)sabot-durand.net&gt; Sent: Wednesday, October 12, 2016 4:43 AM To: cdi-dev Cc: edward.burns(a)oracle.com Subject: [cdi-dev] Moving on SERVLET_SPEC-116 (giving servlet beans to servlet spec) 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@redhat.com<mailto:asd@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@oracle.com<mailto:edward.burns@oracle.com>> Cc: Shing Wai Chan <shing.wai.chan@oracle.com<mailto:shing.wai.chan@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-o... On Tue, Oct 11, 2016 at 5:26 PM, Edward Burns <edward.burns@oracle.com<mailto:edward.burns@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": 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. 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. 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@oracle.com<mailto:edward.burns@oracle.com> | office: +1 407 458 0017<tel:%2B1%20407%20458%200017> [1] https://java.net/projects/servlet-spec/lists/jsr369-experts/archive/2014-... [2] https://java.net/projects/servlet-spec/lists/users/archive/2014-11/messag... ________________________________ 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.