Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jaxrs-dev] Integrating JAX-RS, CDI and bean validation
Hi,

On Sun, Mar 4, 2018 at 11:56 AM, Christian Kaltepoth <christian@xxxxxxxxxxxx> 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


 


Christian


--
Christian Kaltepoth


_______________________________________________
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


Back to the top