Excellent. I'll do some experimenting with it, but I think it will be the best path forward. Let's see if anyone from Jersey has an opinion too.
In RESTEasy what I've done is just explicitly added @Inject to any member with a @Context and it seems to be working. I'm working through some implementation issues, but nothing too bad yet.
I am not a CDI expert. If it is possible to keep @Context and make it a CDI qualifier without running into a lot of side-effects aka troubles, I would say let's do that. In the end it makes migration easier for users if they CAN switch to @Inject
I am not a CDI expert. If it is possible to keep @Context and make it a CDI qualifier without running into a lot of side-effects aka troubles, I would say let's do that. In the end it makes migration easier for users if they CAN switch to @Inject but are
not FORCED to do that. My intention when originally asking to get rid of @Context was that I actually wanted to get rid of the separate injection framework implied. If @Context can stay in the boat while still getting rid of that separate framework, I'm all
in.
-Markus
Am 09.10.2026 um 18:58 schrieb James Perkins via rest-dev:
Hello All,
This week I've been working on integrating Jakarta REST 5.0 CDI integration into RESTEasy. I've found a couple minor issues we'll need to address in the spec. However, I'd first like to talk about
@Context. We deprecated that annotation, but now I'm wondering if we should instead make not deprecate it and make it a CDI qualifier. The biggest reason for this would be we do need some kind of a qualifier to inject the `ServletConfig` and `ServletContext`.
If we don't have a qualifier, then there is a chance we get the wrong instance injected. Making the `@Context` a CDI qualifier would allow the implementation and user to know they're getting the correct instances injected.
The other two issues are more minor and just documentation changes I hadn't thought about until I fully implemented some things. I'll send up a PR those and for making the @Context a CDI qualifier, but that will be a separate commit in case others disagree.
It will make it easier to delete.
James R. Perkins
Software Developer
IBM
_______________________________________________
rest-dev mailing list
rest-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org