| Reza,
The reason for switching to CDI is that there are currently two competing DI’s in Jakarta REST and there are many edge cases where these do not happily co-exist. Moreover, the CDI integration itself isn’t perfect because of backward compatibility constraints. It is generally a bad idea to have multiple APIs that overlap like these, and this is one of those cases.
I can understand the argument that CDI may provide more than what is necessary (at least for Jakarta REST) but that can be solved by modularizing CDI rather than continuing to support multiple DI’s for different use cases. CDI goes far beyond dependency injection, and for many Jakarta REST applications the rest (no pun intended) isn’t needed.
I hope it is clear that we are not talking just about two annotations (@Inject vs. @Context) but the semantics around them (including scopes, bean initialization, etc). By dropping the @Context-based DI, things can be simplified and edge cases eliminated.
— Santiago
In general honestly I agree. One of the key reasons Jakarta EE still remains relevant despite all its challenges is because it has always made an effort to try to empower a broader ecosystem where it can. The bellwether for me is the likelihood of Spring users integrating the API. If that likelihood is high, we should try to avoid making CDI a hard requirement. Why not continue to support @Context as a fallback to CDI in environments where CDI is not available?
Reza Rahman Jakarta EE Ambassador, Author, Blogger, Speaker
Please note views expressed here are my own as an individual community member and do not reflect the views of my employer.
Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone
-------- Original message -------- Date: 6/27/20 12:22 PM (GMT-05:00) Subject: Re: [jakarta.ee-community] [jakartaee-ambassadors] Re: Jakarta EE Backlog -> Guide to Jakarta EE 10
Hello Andy,
Thanks for the clarification. I see what you're saying. I guess the key thing is that I'd want it to be implemented in such a way that end users don't have to use CDI.
I'm specifically thinking of frameworks like DropWizard, which, although they use JAX-RS annotations, the general programming model does not use any DI. Even though I personally prefer a CDI-based programming model, I think it's important to allow the community to build frameworks that use JAX-RS and don't have a CDI-based programming model. ___
Kito D. Mann | @kito99 | Java Champion | Google Developer Expert | LinkedInExpert training and consulting: PrimeFaces, PrimeNG, JSF, Java EE, Web Components, Angular
> Is JAX-RS going to require CDI? I'm not sure that's a good idea. Some frameworks use those annotations without any DI.
JAX-RS 3.1 - PLANNED - (Q2 or Q3 2020) - Java SE Bootstrap API. Deprecating @Context: Implementors MUST provide CDI; applications MAY use CDI....
and JAX-RS 4.0 - PLANNED (2021) - Removing @Context: Applications MUST use CDI
Can you elaborate on the drawbacks to using CDI? The footprint (in general) should not increase since JAX-RS has its own DI framework - it's this framework that causes conflicts and increased footprint in environments where both JAX-RS and CDI are used. By removing JAX-RS's DI framework and delegating injection to CDI, this should reduce footprint and complexity - both for vendors and users.
Thanks,
Andy
Hi, Isn't there a @RolesAllowed in Jakarta Security and the idea would be to deprecate it in Jakarta REST in favor of that? If Security needed a little more modularity or a "light" module where Authentication or Authorization may not always be required, I guess that is also something to explore.
Both Authentication and Authorization are very small SPIs, and they are exactly meant for vendors to implement a few things of so that Jakarta Security works on whatever environment. Something like say MP JWT takes about the same to implement from scratch as Jakarta Authentication or Authorization (I know, since I implemented all three ;)).
Kind regards, Arjan Tijms
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
jakarta.ee-community mailing list
jakarta.ee-community@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
_______________________________________________ jakarta.ee-community mailing list jakarta.ee-community@xxxxxxxxxxxTo unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/jakarta.ee-community
|
