For example its default implementation uses the Java ServiceLoader to detect constraint definitions. I don't think that we could completely move the whole concept into ConstraintMapping.
If I understood this code correctly, the main issue would be to defer the service discovery up to the instantiation of the ValidatorFactoryImpl. Other than that, it seems to me that we could provide identical functionality. But I may not fully understand
Also, I never actually liked the fact that constraint-definition is defined in constraint-mapping. Since it is a global configuration I think it might have been better off in validation.xml
Agreed. That's what I thought when I discovered this feature. I supposed it was meant to be some kind of "constraint-mapping", where we map the constraint to a validator, which is (in a way) close to mapping a type/field/method to some constraints. But still, it's a bit odd to mix these things.
It's marked as experimental, so I'm inclined to alter it as described above.
I am more inclined to say to either just go with the current approach or also add explicit support in ConstraintMapping which will complete the mirroring of the functionality of constraint-mapping.xml.
Maybe we could keep the current approach as an experimental feature, to see if there's a way to expand it (I think in particular about full-featured modular configuration, a bit like Jackson's "modules"), and at the same time introduce a less powerful, but more intuitive approach (at least to users coming from XML configuration) in ConstraintMapping? Gunnar, Hardy, would it be okay to you? |