Hi,
In addition, at this point it would seem that the likelihood of Jakarta Rest-4.0’s inclusion in Jakarta EE11 is tenuous at best, so producing a more limited 3.2 Version, that still has value add, might be more of a realistic goal along with easing the eventual transition to tighter integration with CDI.
Thoughts?
It's in a way sad that the transition to CDI, which for JAX-RS actually should have happened in 2009, is again delayed. In our hearts we all know that a platform that consistently uses a single component model and injection system (as our friends from Spring have with their Spring Beans) is far superior to one that is a hodgepodge of different models. Yet year after year we keep delaying this transition and pushing it further out.
IMO we could, probably should, keep the CDI support in so users have something to migrate to with the deprecation of @Context. We should keep the issue of making the resource annotations stereotypes,
https://github.com/jakartaee/rest/issues/952, and have TCK tests which validate that the required types can be injected via CDI.
It gives users a notification, more than just documentation, that one thing is deprecated and the ability to migrate to the "new" thing.
But, we also have to be realistic. If Jakarta REST 4.0 is not ready, it's not ready, and we should ship what we do have.
So a reluctant +1 from me.
Kind regards,
Arjan Tijms
_______________________________________________
rest-dev mailing list
rest-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://accounts.eclipse.org