On Mon, Jul 9, 2012 at 5:48 AM, Hardy Ferentschik <hardy(a)hibernate.org> wrote:
On Jul 5, 2012, at 9:30 PM, Matt Benson wrote:
> Hmm, the foregoing discussion still sidesteps the main subject of this
> thread. Aren't we saying that the current API implies this workflow:
>
> * user calls Configuration#addMapping() 0..n times
> * user calls Configuration#buildValidatorFactory()
> * Configuration passes ConfigurationState to
> ValidationProvider#buildValidatorFactory()
> * ValidationProvider:
> ** queries ConfigurationState#getMappingStreams()
> ** sets up result for Configuration#getConfigurationSource()
> ** returns ValidatorFactory
I think you are wrong. Configuration reads validation.xml and provides the information
found via Configuration#getConfigurationSource().
In fact the Configuration implementation has to read validation.xml, because a custom
validation provider could be defined.
Hmm... Typically my viewpoint comes from my experience in the guts of
Apache BVal; I usually try to stay out of you guys' code due to Apache
IP process and a sense of fun. :) However, your statements above
don't seem to be borne out by Hibernate Validator's bootstrap code,
AFAICT. I followed the services definition for ValidationProvider to
HibernateValidator, whose implementation of #buildValidatorFactory()
sends the ConfigurationState to the ValidatorFactoryImpl constructor,
which then invokes the objects that process the XML mappings. Clearly
the XML processing takes place beyond the Configuration; your "because
a custom validation provider could be defined" only seems to emphasize
my point.
Best regards,
Matt
--Hardy
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev