Are you suggesting:
- keeping @Body and the injection mechanism used in 3.1 (3.1 injection), ignoring the annotation?
Ideally, yes. The main idea being that there is a migration path.
-
- allowing switching the injection modules (3.1 injection vs CDI injection module) when the customer decides to transition from @Context to @Body
I'm not sure I follow this part completely. I don't follow the @Context -> @Body part.
- need to support @Inject by the 3.1 injection wherever the deprecated @Context would be replaced by @Inject
I'm not a CDI expert, but I think this should be doable. My implementation idea was to treat the ContextResolver's as CDI producers.
- in JBoss (or any application server), you won't be able to use both injection modules at the same time, so only the deprecated injection will be included (to keep the backward compatibility)
There is a good chance I'm missing something here, but we already do this so I'm not sure how it will be a problem. Where I can see it being an issue is with constructor and method injection. However, we could have a hard rule along the lines of "Your resource or provider must use either use CDI injection for methods and constructors or use the deprecated @Context injection for methods and constructors".
- hence the CDI injection won't be testable by the tck running atop the application server
Or are you suggesting:
- teach CDI to understand the @Context and have CDI as the main injection framework
This is something I've thought about looking at TBH. Though that's an implementation detail. I know it's possible to do as this is what Quarkus does.
- update/duplicate all the TCKs to use @Inject and @Body
The hope was that we could, for 3.2 at least, keep the TCK tests as is and add more TCK which test CDI integration. While I understand and respect the need to verify that both methods work, it would be hard to duplicate every single test which uses @Context injection as I'm sure there is a lot. The ones I see duplicating are the ones that explicitly test @Context injection with ContextResolvers.
Another possible option, to support both, is to require that an jakarta.ws.rs.core.Application use either CDI or the 3.1 context injection, but not both. I'm not exactly user how we determine that given the 3.1 method already allows for CDI integration.
One obvious catch to all of this is the client side. That said, we've got this issue whether we do a 3.2 or a 4.0. Client side injection is just not going to work without a CDI container.
2. We
could support both. If possible, not sure on this, we could require implementations to log a warning if the @Body annotation is not used. Effectively supporting both the old and new options
I’ve chatted a bit with James on this and I’m thinking that option 2 is likely the only viable option for Jakarta Rest 3.2. We have to provide an alternative to @Context if we are going to formally deprecate it and I would think that we’d want to also
deprecate @Suspended as well. As a result there may be more than one un-annotated parameter, so support for @Body will be needed.
