FYI: Today I will be creating separate issues associated with the action items listing in this email chain (as well as the previous one) so that we can discuss/resolve each of these and eventually include them (and there associated PRs) in the 3.2 (or 4.0) epic. I’ve started with https://github.com/jakartaee/rest/issues/1206 and will be adding more soon. I realize some of these have already been discussed as part of other issues that we can reference. Hopefully I’m not over-stepping with this as I’m just attempting to ensure that all of the issues are clearly resolved so that we will feel comfortable moving ahead with the 3.2 version. Thanks
On Jan 24, 2024, at 9:31 AM, Santiago Pericasgeertsen via rest-dev <rest-dev@xxxxxxxxxxx> wrote:
On Jan 23, 2024, at 2:56 PM, James Perkins <jperkins@xxxxxxxxxx> wrote:
IMO, we need to iron out the technical problems that result from deprecation of @Context first. As we know, deprecation requires an alternative, and in this case providing an alternative may not be straightforward. Does it make sense to work on a release plan, branch etc without a sound technical solution to the problem?
Do I understand correctly that the following types are the only types allowed to be injected with @Context?
- jakarta.ws.rs.core.Application
- jakarta.ws.rs.core.UriInfo
- jakarta.ws.rs.core.Request
- jakarta.ws.rs.core.HttpHeaders
- jakarta.ws.rs.core.SecurityContext
- jakarta.ws.rs.ext.Providers
- jakarta.ws.rs.container.ResourceContext
- jakarta.ws.rs.core.Configuration
- jakarta.servlet.ServletConfig
- jakarta.servlet.ServletContext
- jakarta.servlet.http.HttpServletRequest
- jakarta.servlet.http.HttpServletResponse
I didn’t check this, but seems correct. And any type for which a ContextResolver<T> is defined (aka producer).
This is where I'm wondering if I'm missing something TBH. I looked at the TCK and through the RESTEasy tests as well as read over the 3.1 specification. I don't see where you can inject a type that a ContextResolver resolves with @Context. All the examples I see inject the Providers and lookup the ContextResolver to resolve the context type. Am I missing something? I might very well be, which is why I'm asking :) FWIW I thought it would work too, but all my local testing shows the injected values to always be null.
Right, I think you’re correct in your analysis, this is only done programmatically. So it boils down to having support to inject Providers. However, having a method called `getContextResolver` in Providers when @Context is deprecated may be a bit odd —but again backward compatibility is imperative here. If so, I don't really understand why CDI won't work here.
We currently run with and without CDI, in particular, resources and providers don’t need to be CDI beans (and there’s no need for any beans.xml file). Assuming CDI is always available is sort of a big change and maintaining backward compatibility may be an issue (e.g., final classes may be problematic with Weld). Ignoring that for a moment, injection into fields/properties and constructors (this would require the class to be a CDI bean also) should be possible. I do understand how this could be an issue in SeBootstrap, unless we require a CDI container, and the client. However, in a Jakarta EE Container I see no reason why we can't just use @Inject. I realize for method parameters it's a bit different, but with CDI Method Invokers, https://github.com/jakartaee/cdi/pull/639, we should be able to handle that.
Hmmm, maybe. In general, this all sounds like a big change for dot release. Perhaps it is time to prototype something to learn more about these challenges?
As of now using CDI to inject the known types listed above does work in RESTEasy for fields. We need to do some work to have it work on constructor and method injection though. I plan on working on this week or next week for sure.
Roger, excellent.
— Santiago
_______________________________________________rest-dev mailing listrest-dev@xxxxxxxxxxxTo unsubscribe from this list, visit https://accounts.eclipse.org
|
