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


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.
ok, that makes things easier.

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.

ok, so you have a problem with using the Locale directly on the producer side and I have a problem with using the LocaleResolver on the consumer side:

* either you get a validation that is different depending whether it is executed directly on JAX-RS objects (where JAX-RS can use its own validator) or on a backing bean that uses the default validator.
* or BV must find out about the current calling context on a backing bean and know how to use the JAX-RS LocaleResolver (and the one from MVC and from all other technologies) which gives you tight coupling of the specs and the inability to add the next-gen technology without updating validation.

So perhaps the solution is to have one (or multiple) LocalProducers and have JAX-RS evaluate them and provide the locale. I guess something like this is what Arjan meant with his references to the identity stores:

@RequestScope
public class LocaleResolverHandler {
  @Inject @Any
  private
Instance<LocaleResolver> resolvers;


  @Produces
  public Locale produceLocale() {
    // should be sorted by priority first...
    for (LocaleResolver lr : resolvers) {
      if (lr.canResolve()) {
        return lr.resolveLocale();
      }
    }
    return Locale.getDefault();
  }
}

Best regards,
  Niklas
 

Back to the top