[bv-dev] Dependency between constraints and validators

Emmanuel Bernard emmanuel at hibernate.org
Mon Oct 24 04:31:23 EDT 2011

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.


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

More information about the beanvalidation-dev mailing list