| Re: [jaxrs-dev] Integrating JAX-RS, CDI and bean validation |
+1 for mandatory CDI in 3.0
-Markus
From: jaxrs-dev-bounces@xxxxxxxxxxx [mailto:jaxrs-dev-bounces@
eclipse.org ] On Behalf Of Santiago Pericas-Geertsen
Sent: Montag, 5. März 2018 16:30
To: jaxrs developer discussions
Subject: Re: [jaxrs-dev] Integrating JAX-RS, CDI and bean validation
All,
I certainly second the opinion that having multiple injection mechanisms is a nightmare, unfortunately that’s how things evolved under the requirement to maintain backward compatibility.
Interestingly, we sort of started going in this direction with MVC. Here is an interesting statement from the MVC spec:
"Unlike in JAX-RS where resource classes can be native (created and managed by JAX-RS), CDI beans, managed beans or EJBs, MVC classes are REQUIRED to be CDI-managed beans only [[mvc:cdibeans]].”
Naturally, for JAX-RS, this would be a breaking change. However, if we decide to go for a new major version (3.0?) we should definitely put this discussion on the table.
— Santiago
On Mar 4, 2018, at 10:28 AM, arjan tijms <arjan.tijms@xxxxxxxxx> wrote:
Hi,
On Sun, Mar 4, 2018 at 11:56 AM, Christian Kaltepoth <christian@
kaltepoth.de > wrote:Improving integration with CDI is one of the most important things to achieve in the short term. At least in my option.
I fully agree with this.
Here we can definitely learn something from Spring, where simply everything is a Spring Bean. There's not ~6 different largely independent injection mechanisms and 6 different bean models. Although I'm not that deeply intrenched in how Spring development takes place, from the things I've seen I don't believe they often argue about not being able to depend on Spring Beans since some user who's using CDI might want to use their code as well (please correct me if I'm wrong here).
But building features exclusively on CDI is something which will take more time. Especially it would require the deprecation of the @Context injection feature of JAX-RS and I'm not sure if this will happen in the short term. But I'm just guessing here.
I personally think it should happen in the short term. Deprecation doesn't mean it's gone, but gives a signal. it has been almost 8 years since CDI was introduced and far too little progress has been made. New specs/open-apis like MicroProfile but MVC and Java EE Security as well simply declared being CDI first, and this has worked quite well until now.
Note that implementations of JAX-RS such as Jersey and Rest-easy can of course keep supporting whatever they want, just as e.g. Hibernate has plenty of features that go beyond JPA. But for the spec JAX-RS I think we really should deprecate @Context rather sooner than later.
I think that's a matter of taste. I love CDI, but in this case I prefer the explicit contract of the LocaleResolver interface over using CDI injection of the locale directly. Especially because such SPIs work much better if you can have multiple resolvers which may or may not be able to provide the locale. This would be difficult to handle with CDI.
You could maybe take a look at the Java EE Security API. This looks a little like the multiple identity stores that we support, and which may or may not be able to support the credentials that the caller provided. We handled this fully in CDI.
Sure, that would work, but it would also be very complex to have different specification layers. But I agree that how to handle the JAX-RS vs. CDI relation is a key decision.
In my opinion we should not add extra layers of complexity to design something for the 20% or even less out there. This has hold back Java EE specifications in the past and has even burned some. Keep it simple, go for CDI, and if someone wants something else they can build a CDI bridge themselves, or do something proprietary.
My 2 cents ;)
Kind regards,
Arjan
_______________________________________________
jaxrs-dev mailing list
jaxrs-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jaxrs-dev
______________________________
_________________ jaxrs-dev@xxxxxxxxxxx
jaxrs-dev mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jaxrs-dev
_______________________________________________
jaxrs-dev mailing list
jaxrs-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/jaxrs-dev