On 26 oct. 2011, at 15:47, Kevin Pollet wrote:
On 25 October 2011 14:34, Emmanuel Bernard <emmanuel(a)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
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
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
Any one with better knowledge of OSGi or any other modular environment want to shred some
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.