[bv-dev] BVAL-265 - Expose settings defined in XML in the Configuration API

Matt Benson mbenson at apache.org
Mon Jul 9 11:27:47 EDT 2012


On Mon, Jul 9, 2012 at 9:44 AM, Matt Benson <mbenson at apache.org> wrote:
> On Mon, Jul 9, 2012 at 5:48 AM, Hardy Ferentschik <hardy at 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.

Okay, I see now where I've gone wrong.  I mistakenly interpreted
"mapping" resources as encompassing configuration/bootstrap
information as well.  *Mapping* resources are processed by a given
ValidationProvider; *Configuration* resources are processed by the
Configuration.  I see now that ConfigurationSource is more or less a
"stringified" version of ConfigurationState plus the default provider
classname, minus #ignoreXmlMapping().

My apologies for the confusion, and thanks for your patience!  ;)

Matt

>
> Best regards,
> Matt
>
>>
>> --Hardy
>>
>>
>> _______________________________________________
>> 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