| Re: [jakarta.ee-community] [jakartaee-ambassadors] Re: Jakarta EE Backlog -> Guide to Jakarta EE 10 |
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 -------- From: Kito Mann <kito.mann@xxxxxxxxxx> Date: 6/27/20 12:22 PM (GMT-05:00) To: Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx> Cc: Jakarta EE Ambassadors <jakartaee-ambassadors@xxxxxxxxxxxxxxxx> 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 | LinkedIn Expert training and consulting: PrimeFaces, PrimeNG, JSF, Java EE, Web Components, Angular On Fri, Jun 19, 2020 at 2:28 PM Andy McCright <j.andrew.mccright@xxxxxxxxx> wrote:
|