On 25 October 2011 14:34, Emmanuel Bernard
<emmanuel@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.