Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jakarta.ee-community] [jakartaee-ambassadors] Re: Jakarta EE Backlog -> Guide to Jakarta EE 10

Good points, Arjun. And that's what I was hoping -- that it's more of an implementation detail for Jersey as opposed to a requirement for creating an endpoint. For example, in DropWizard apps, you use JAX-RS annotations, but to register your resource, you actually do it imperatively:

    final HelloWorldResource resource = new HelloWorldResource(
        configuration.getTemplate(),
        configuration.getDefaultName()
    );
    environment.jersey().register(resource);

So there's no use of @Named or anything; you create and initialize the object via its constructor.

___

Kito D. Mann | @kito99 | Java Champion | Google Developer Expert | LinkedIn
Expert training and consulting: PrimeFaces, PrimeNG, JSF, Java EE, Web Components, Angular
Virtua, Inc. | virtua.tech 

* Enterprise development, front and back. Listen to stackdpodcast.com.




On Sat, Jun 27, 2020 at 2:13 PM arjan tijms <arjan.tijms@xxxxxxxxx> wrote:
Hi,

I hear you, though in this particular case it might not be such a problem. If Jersey can use HK2 under the covers, then why not CDI?

I wonder if the average DropWizard user is even aware that Jersey uses HK2 under the hood. It's surely not something the environment has to supply very explicitly (Jersey 2.26+ made this a little more explicit, but only a little more).

It becomes more interesting even given the plans of Payara to move HK2 into a full CDI implementation. What then? Jersey will then already use CDI under the hood as well, and, probably, still without DropWizard users being much aware of that.

Kind regards,
Arjan







On Sat, Jun 27, 2020 at 7:12 PM m.reza.rahman <m.reza.rahman@xxxxxxxxx> wrote:
The real truth is probably that the perception problems you are alluding to has to do with the hypercompetitive nature of our industry. That's why CDI is seen as being more "contentious" than things like REST/@Context, Persistence and Servlet. Nonetheless, it is an ecosystem reality we should probably try to respect when possible. The risk of not doing so is limiting the adoption of these technologies and thus really becoming more of a de-jure standard rather than something that is both a de-facto standard and an open standard/specification.

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: arjan tijms <arjan.tijms@xxxxxxxxx>
Date: 6/27/20 12:57 PM (GMT-05:00)
To: reza_rahman <reza_rahman@xxxxxxxxx>
Cc: Jakarta EE community discussions <jakarta.ee-community@xxxxxxxxxxx>, Jakarta EE Ambassadors <jakartaee-ambassadors@xxxxxxxxxxxxxxxx>
Subject: Re: [jakarta.ee-community] [jakartaee-ambassadors] Re: Jakarta EE Backlog -> Guide to Jakarta EE 10

Hi,

On Sat, Jun 27, 2020 at 6:33 PM reza_rahman <reza_rahman@xxxxxxxxx> wrote:
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.

I'm not sure, don't Spring users have Spring MVC?
 
Why not continue to support @Context as a fallback to CDI in environments where CDI is not available?

I wonder if some of these environments actually use Jakarta REST, or whether they don't just use Jersey? I might be mistaken, but I think DropWizard falls more into the Jersey category.

Also, the problem I'm seeing is that environments that didn't have JAX-RS available, made JAX-RS available by adding (say) Jersey. Likewise, JAX-RS uses bean validation, so environments that didn't have that available added bean validation. Internally, Jersey uses HK2. Again, environments that didn't have HK2 available (which I dare assume to say is most of them) added HK2.

As far as I know, it hasn't been common to ask for Jersey not using HK2 anymore and provide a fallback for (say) Spring. 

I'm curious why then CDI (say Weld) is so much different? Is there actually a technical reason for this, or is something else?

Kind regards,
Arjan Tijms






 

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
Virtua, Inc. | virtua.tech 

* Enterprise development, front and back. Listen to stackdpodcast.com.




On Fri, Jun 19, 2020 at 2:28 PM Andy McCright <j.andrew.mccright@xxxxxxxxx> wrote:
> Is JAX-RS going to require CDI? I'm not sure that's a good idea. Some frameworks use those annotations without any DI. 

Yes, the plan is for JAX-RS to require CDI.  See https://github.com/eclipse-ee4j/jaxrs-api/wiki/Roadmap

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  

On Fri, Jun 19, 2020 at 12:26 PM arjan tijms <arjan.tijms@xxxxxxxxx> wrote:
Hi,

On Fri, Jun 19, 2020 at 5:53 PM Werner Keil <werner.keil@xxxxxxxxx> wrote:
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

--
You received this message because you are subscribed to the Google Groups "Jakarta EE Ambassadors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jakartaee-ambassadors+unsubscribe@xxxxxxxxxxxxxxxx.
To view this discussion on the web visit https://groups.google.com/d/msgid/jakartaee-ambassadors/5ef774de.1c69fb81.4f77f.5ea6SMTPIN_ADDED_MISSING%40gmr-mx.google.com.

--
You received this message because you are subscribed to the Google Groups "Jakarta EE Ambassadors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jakartaee-ambassadors+unsubscribe@xxxxxxxxxxxxxxxx.
To view this discussion on the web visit https://groups.google.com/d/msgid/jakartaee-ambassadors/CAE%3D-AhB4Osjha1_APgr18JkW9mX%2B0F8Z46ozXwYSbfeFDBJEzw%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "Jakarta EE Ambassadors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jakartaee-ambassadors+unsubscribe@xxxxxxxxxxxxxxxx.
To view this discussion on the web visit https://groups.google.com/d/msgid/jakartaee-ambassadors/CAE%3D-AhAx6H4PD7Tzx011%3D60_aR-sbMpm6CL4XwO4j8weP-J1kA%40mail.gmail.com.

Back to the top