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:
I think method parameters are going to be the most difficult as the *Param annotations are allowed on the parameters themselves. That said, that part is an issue with a potential 3.2 or 4.0.
One thing I haven't seen is if it's been decided, even for 4.0, is if we've decided to go with CDI 4.1. I ask because CDI 4.1 introduced method invokers specifically for REST methods.
1. Needs to be fully backward compatible in 3.2
I can definitely see some issues here mostly around the client side where there is no CDI container. Again though this is something we need to address in 4.0 as well.
2. Migrating all TCKs to avoid the deprecation messages is a lot of work
Do we need to do this? IMO it's okay to test because we want to make sure it still works. However, maybe I'm wrong there.
3. We cannot introduce a static dependency with CDI, still needs to be optional
Agreed and again this needs to be answered for 4.0 as well. If it was, I missed it and apologize :)
4. Need to figure out the entity annotation problem
Yes, thinking about it, it feels easy to resolve. However, I've not tried implementing it so I could be wrong. My initial idea was to look for a @Body annotation and not allow any other non-injectable types with no annotation. If there is no @Body, assume, like in 3.1, that the parameter is the body. That might be a bit naive though.
5. How to deal with ContextResolver(s)
While I've definitely not tried to implement this, my initial thought was to make them producers in a CDI extension.
Brings back memories as to why we didn’t do this before ...
I completely apologize if I'm bringing up things that have been discussed in the past and I missed them. I realize I'm pretty new to this and I definitely don't want to revisit things that have already been settled.
— Santiago
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$
_______________________________________________
rest-dev mailing list
rest-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org
