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


Well. This would require modifications in CDI, BV and JAX-RS. This will be difficult to coordinate. Although this could be a nice solution from a platform perspective.

If this is the right way to do it, we should at least try. Otherwise we'll get a more complicated solution just because it is easier to do. Also specifying that a locale is available for injection in the request context of JAX-RS would already help even if the other specifications are not updated.

Of course we should find the best solution for the overall platform. No doubt about that. But we are in a weird situation, because the standardization process isn't even defined yet. So we don't know how the next JAX-RS version will become an official standard and therefore coordination between different specs is even more difficult. So maybe it is just to early for this.
 

I totally agree with you that the default of using the server locale does not make a lot of sense. But regardless of what we decide, changing the default behavior will be less of a technical challenge, but a question of whether keeping the spec backwards compatible is more important than getting a better default behavior or not.

Well, backwards compatibility is one of the major strength of Java EE and I hope this won't change with Jakarta EE. But as the locale used for validation isn't defined yet in the JAX-RS spec, we are IMO open to decide freely about changing that.


Regarding the CDI requirement: I guess we have to decide which way we are heading. Should this ticket https://github.com/eclipse-ee4j/jaxrs-api/issues/569 be implemented, we would definitly have a dependency on CDI and could then always depend on CDI.

Improving integration with CDI is one of the most important things to achieve in the short term. At least in my option. 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.

 

On the other hand adding an interface like the LocaleResolver in MVC:

Locale resolveLocale(LocaleResolverContext context)

indicates more or less that we are not using dependency injection (CDI already defines the context we are in, so why define another LocaleResolverContext?).

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.

 
So I think this is a strategic decission, that has to be made: What is the JAX-RS relation to CDI? Will it depend on it? Is it just an option?  I have no idea what others think about this or whether there is some kind consensus on how to proceed.

One way of working around this issue could perhaps be to split the specification: The main part that specifies the requirements JAX-RS has on the container in general terms e.g "a locale is provided in the context of the request" and a second part that specified the "binding" of these terms to a specific environment:
* CDI Binding: A producer method can be defined, injection is done using @Inject
* Standalone Binding: ContextResolver and LocaleResolver are used to retrieve the Locale, injection is done using @Context

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.


Christian


--
Christian Kaltepoth

Back to the top