Hi,
It’s not easy to provide an alternative to @Context in 3.2. We need to analyze each type of injection point individually (constructors, fields, properties and method arguments). Some initial thoughts:
1. Needs to be fully backward compatible in 3.2
2. Migrating all TCKs to avoid the deprecation messages is a lot of work
3. We cannot introduce a static dependency with CDI, still needs to be optional
4. Need to figure out the entity annotation problem
5. How to deal with ContextResolver(s)
Brings back memories as to why we didn’t do this before ...
— Santiago
On Jan 17, 2024, at 7:43 AM, Jan Supol via rest-dev <rest-dev@xxxxxxxxxxx> wrote:
Are you suggesting:
- keeping @Body and the injection mechanism used in 3.1 (3.1 injection), ignoring the annotation?
- allowing switching the injection modules (3.1 injection vs CDI injection module) when the customer decides to transition from @Context to @Body
- need to support @Inject by the 3.1 injection wherever the deprecated @Context would be replaced by @Inject
- 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)
- 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
- update/duplicate all the TCKs to use @Inject and @Body
Or something else?
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.
_______________________________________________
rest-dev
mailing list
rest-dev@xxxxxxxxxxx
To
unsubscribe from this list, visit https://urldefense.com/v3/__https://accounts.eclipse.org__;!!ACWV5N9M2RV99hQ!Kwzg2pkpyVLiEtXSqPnjGDSglMHxL2O0tClkAImyPaOsKD-Ig66trlBf1GPkFGNFMzkaiBYEJVb2RczFEZzHe0sJs0Jg$
|