Migrate the CDI integration requirements from the CDI component project to the Platform project

[starksm64]

As part of the EE 11 release plan, there was a desire to break up the CDI EE integration requirements and TCK to the platform. This issue is to track that migration effort.

• Migrate the CDI specification EE integration requirements to the Platform/Web Profile specifications
• Migrate the CDI integration TCK to the platform TCK as a new standalone TCK

[jim-krueger]

As part of this Jakarta Rest is going to need CDI/Servlet support for the following interface classes whose injection was previously supported by @context injection:

• jakarta.servlet.ServletConfig

• jakarta.servlet.ServletContext

• jakarta.servlet.HttpServletRequest

• jakarta.servlet.HttpServletResponse

See the Jakarta Rest 3.1 Spec for historic information.

[starksm64]

@jim-krueger do you have a proposed delta I should include in the #838 PR?

[jim-krueger]

Section 9.8 of the CDI 4.0 spec requires servlet containers to make jakarta.servlet.ServletContext and jakarta.servlet.HttpServletRequest injectable. I'm asking that jakarta.servlet.ServletConfig and jakarta.servlet.HttpServletResponse be added to that list.

[Emily-Jiang]

If the above is added, please remember to add the corresponding TCK @starksm64 @jim-krueger

[manovotn]

I am not overly familiar with servlet spec, so brace yourselves for silly questions :)
I was trying to think how to expose these two interfaces as beans and what would it mean.

I'm asking that jakarta.servlet.ServletConfig

The only notion of this in the spec seems to be here. How do you normally gain access to this object? Is it accessible through current http request?

and jakarta.servlet.HttpServletResponse be added to that list.

This one I find harder to wrap my head around - I'd guess this should be a req. scoped bean but by the time CDI req. context activates, I don't think the HttpServletResponse exists. Please correct me if I am wrong, but Weld currently hooks into ServletContextListener and uses contextInitialized event to both, store http request and init its req. context - and that seems to early for HTTPServletResponse to exist, right?
Plus, what are you current options in how to retrieve HTTPServletResponse object assuming you know the corresponding HTTPServletRequest?

[jamezp]

I just looked more into this and I actually don't think the ServletConfig can be injected. Every servlet has a ServletConfig and in the case of Jakarta REST the desired ServletConfig is configuration for the jakarta.ws.rs.core.Application. The Jakarta Servlet spec or CDI can't have a producer for this as it would rely on the Jakarta REST API. Not relying on the Jakarta REST Spec a qualifier of some sort would be required to be able to inject the ServletConfig when there is more than one servlet. I don't think this can be done.

The HttpServletResponse will be a real problem too. I don't know that there would be a way to do this. I can say that RESTEasy gets the HttpServletResponse from the HttpServlet.service(ServletRequest, ServletResponse) invocation. Which will likely happen after the RequestScoped scope is created.

[jamezp]

Thinking a little more about the HttpServletResponse. Could we have an interim object, forgive the name, but something like ServletService which has a method like:

public CompleteableFuture<HttpServletResponse> getHttpSerletResponse() {}

Then we allow the ServletService to be injected. I don't know how the Servlet spec would handle that, but it might work.

[manovotn]

Thinking a little more about the HttpServletResponse. Could we have an interim object, forgive the name, but something like ServletService which has a method like:

public CompleteableFuture<HttpServletResponse> getHttpSerletResponse() {}

Then we allow the ServletService to be injected. I don't know how the Servlet spec would handle that, but it might work.

Maybe, but that doesn't exactly address the original request and you need to take an extra step to gain access to the http response. But yea, I have nothing better 🤷