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).
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?
