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.

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

Emmanuel

On 24 oct. 2011, at 22:08, Gunnar Morling wrote:

> Hi,
>
>> - we would need to scan libs - talk to the CDI guys, this is not a trivial problem and at least forces people to put META-INF/bean.xml files in their JARs
>
> Would probably be the simplest solution for constraint authors and
> users, but I agree that this would be everything but easy. So I guess
> this approach is out of scope at least for BV 1.1.
>
>> - we would need to list all bindings in an XML DD (this solution already exists in BV 1.0)
>
> Right, that works. One problem I still see from the POV of a
> constraint author is that as of BV 1.0 each constraint mapping must be
> imported in validation.xml. So a constraint library author could
> create distinct JARs for constraints and validators but the user still
> would need to import the mapping XML files.
>
> I think that's a general thing which we should cover in BV 1.1: enable
> the creation of re-usable constraint libraries which can easily be
> thrown into a project. Maybe this would en passant address the cycle
> problem.
>
>> - we would need to list all binding via a programmatic API (that solution does break compile time checking BTW)
>
> Why would that break compile-time type-safety?
>
> --Gunnar
>
>
> 2011/10/24 Emmanuel Bernard <emmanuel@hibernate.org>:
>> I personally am not bothered by this especially when comparing the drawbacks of alternatives:
>> - we would need to scan libs - talk to the CDI guys, this is not a trivial problem and at least forces people to put META-INF/bean.xml files in their JARs
>> - we would need to list libs in an XML DD
>> - we would need to list all bindings in an XML DD (this solution already exists in BV 1.0)
>> - we would need to list all binding via a programmatic API (that solution does break compile time checking BTW)
>> - we would rely one some naming convention (not type-safe and require package scanning which is not trivial either esp in funny environments that use custom URL protocols)
>> - we would rely on the container to provide the information - which means SE becomes a second class citizen
>>
>> We can imagine less evil solutions like a "factory" class declared in the XML DD and describing the binding programmatically but I'm not yet convinced of the benefits. For that we would need to explore the programmatic configuration topic first though.
>>
>> Emmanuel
>>
>> On 23 oct. 2011, at 20:10, Gunnar Morling wrote:
>>
>>> Hello experts,
>>>
>>> one thing about BV I'm somewhat uncomfortable with is the (cyclic)
>>> dependency between constraint annotation types and their validators.
>>> This is, validators are referenced from constraints within the
>>> @Constraint meta-annotation, while constraint types are referenced by
>>> the type parameter in validator impl's.
>>>
>>> In particular this makes it impossible to clearly distinguish between
>>> the public API of a constraint library (the annotation types) and its
>>> implementation (the validators), e.g. by creating two distinct JARs.
>>>
>>> Therefore I'd personally prefer if there was only a reference from the
>>> validators to the constraints, but not the other way around. This of
>>> course raises the question how it would be determined which validators
>>> exist for a given constraint. One could think of using XML descriptors
>>> or some scanning-based approach. I guess from a technical POV this
>>> problem is somewhat related to what's to be done in CDI (finding bean
>>> implementations, processing qualifier annotations etc.).
>>>
>>> That said, I'd be very interested in your opinion on this topic. Do
>>> you think this is something we should address or do you think this
>>> sort of cycle is acceptable?
>>>
>>> Thanks,
>>>
>>> --Gunnar
>>> _______________________________________________
>>> beanvalidation-dev mailing list
>>> beanvalidation-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>
>>
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev