Re: [bv-dev] Dependency between constraints and validators

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