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