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 Marko,

I don't know if BV is really the best place to decide which of the languages to use.
For an international application I guess most people will want to decide beforehand what languages to support.

So if an application supports EN and FR with EN being the fallback and a browser sends ES, EN as supported languages, I'd expect the application to completely fall back to english.
If the validaton message for @NotNull is suddenly returned in spanish (because hibernate validator comes with spanish support by default) but everything else is in english, that would be confusing and probably not what people want.

By default I guess the decision what locale to use should be made in JAX-RS (with the possiblity to override this behavior in BV if an elaborate fallback scheme based on all listed locales is required).

Best regards,
  Niklas


2018-03-07 19:16 GMT+01:00 Marko Bekhta <marko.prykladna@xxxxxxxxx>:
Hi all,

Thought I'll join this discussion. Note that there's also a plan to explore a
possibility of receiving multiple locales by BV (actually Hibernate Validator -
https://hibernate.atlassian.net/browse/HV-1436). In case of multiple locales in
request headers we cannot assume that the one with higher priority should be
used, as for example there could be no message available for that particular
locale but for the next one by priority.

Have a nice day,
Marko

2018-03-07 17:28 GMT+01:00 Christian Kaltepoth <christian@xxxxxxxxxxxx>:
I'm also +1 for mandatory CDI in JAX-RS 3.0!

However, back to the topic of which locale to use for BV messages: I'm still not completely sure if this is really something JAX-RS should address. Niklas already brought up that different locale selection rules between JAX-RS, MVC and CDI/EJB method validation is very confusing. So maybe this is something that should be clarified in BV directly?

Christian 

2018-03-05 21:57 GMT+01:00 Markus KARG <markus@xxxxxxxxxxxxxxx>:

+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

 

 

 

 

 

Christian

 

 

-- 


_______________________________________________
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 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 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 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 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