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@lists.jboss.org <cdi-dev-bounces@lists.jboss.org> on behalf of Antoine Sabot-Durand <antoine@sabot-durand.net>
Sent: Wednesday, October 12, 2016 4:43 AM
To: cdi-dev
Cc: edward.burns@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>
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>
Cc: Shing Wai Chan <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-of-HttpServletRequest-is-injected-td5713578.html#a5713688

On Tue, Oct 11, 2016 at 5:26 PM, Edward Burns <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":

>>>>> On Wed, 19 Nov 2014 15:55:43 -0500 (EST), Stuart Douglas <sdouglas@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@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@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@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