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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

- 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 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 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 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)

From the class, we can infer the @Constraint being validated.

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(a)hibernate.org&gt;: > 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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev > > > _______________________________________________ > beanvalidation-dev mailing list > beanvalidation-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev > _______________________________________________ beanvalidation-dev mailing list beanvalidation-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

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?

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(a)hibernate.org&gt;: >> 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(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev >> >> >> _______________________________________________ >> beanvalidation-dev mailing list >> beanvalidation-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev >> > _______________________________________________ > beanvalidation-dev mailing list > beanvalidation-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev _______________________________________________ beanvalidation-dev mailing list beanvalidation-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

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.