[bv-dev] Dependency between constraints and validators

[Emmanuel Bernard]

On 26 oct. 2011, at 15:47, Kevin Pollet wrote:

> Hi,
> 
> On 25 October 2011 14:34, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
> Your email made me think of a potential solution.
> 
> We could use the service loader pattern to declare a constraint implementor service that would list the bindings between a constraint and its implementation.
> 
> Add in implementation jars
> 
>    META-INF/services/javax.validation.ConstraintValidator
> 
> where `javax.validation.ConstraintValidator` contains the list of fully qualified class names of constraint implementations.
> 
> >From the class, we can infer the @Constraint being validated.
> 
> I think this works very well:
> 
> - this list is compiled when ValidatorFactory is built
> - this list can be equally built by the compiler and thus the annotation processor has equal knowledge
> 
> The only gotcha I can see is that in modular environments like OSGi and co. They tend to hide such files from the classpath. So discovering the various resources named `META-INF/services/javax.validation.ConstraintValidator` might be flaky.
> That's an open subject in any case (ie. making BV run better in modular environments).
> 
> Any one with better knowledge of OSGi or any other modular environment want to shred some lights?
> 
> I'm not an OSGi expert but I've already implemented such mechanism to discover BV implementations, with a custom ValidationProviderResolver, in OSGi. For this test I've used the following design, one bundle for the api and one bundle per implementation (the common use case). 
> 
> In OSGi, the bundle resources are hidden to others bundle. To get something like that working you need to iterate on all bundles and check if the `META-INF/services/javax.validation.ConstraintValidator` is present with the bundle classloader. The main issue here is to deal with dynamism but that's not the goal :-) One drawback with that approach is that you expose your implementations which tend to be hidden in a modular world.

That's the thing, it can be hidden from the application bundles but it must be visible from frameworks bundles (whether ootb in the app server or provided in the application.

> 
> IMHO, if the mechanism used to discover the ConstraintValidator implementations is pluggable, it should work.

What do you have in mind? I don't mind having a pluggable discovery mechanism but we need a standard way for a constraint implementor to expose the fact that it implements validators for some constraints.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20111026/82386958/attachment.html