[bv-dev] Invoking Configuration#buildValidatorFactory() several times

[Gunnar Morling]

Hi,

>  In this case it would still be up to the implementation to support > 1 calls to Configuration#buildValidatorFactory()

In HV, we're currently thinking about using InputStream#mark() and
reset() to re-read the mapping streams. That the stream supports
mark/reset, would have to be ensured by the user, or alternatively we
might wrap the given streams ourselves into resettable ones. It might
make sense that the spec mandates such a behavior.

--Gunnar


2012/3/26 Matt Benson <mbenson at apache.org>:
> On Thu, Mar 22, 2012 at 10:32 AM, Emmanuel Bernard
> <emmanuel at hibernate.org> wrote:
>> I created ConfigurationState for a different reason (separating the bootstrap logic from the provider) but indeed I think we should allow Configuration to be reusable though we will have to be careful on the wording.
>
> On this subject, the ConfigurationState must be able to supply mapping
> streams including those specified in the xml config (if, of course,
> Configuration#ignoreXmlConfiguration() is not called) and those
> specified directly via Configuration#addMapping().  The latter
> mappings are not available for subsequent uses of
> Configuration#buildValidatorFactory() unless an implementation
> proactively caches the contents of these streams.  I wonder if BV v1.1
> should use something like javax.activation.DataSource for the
> programmatic API (I'm not sure of the targeted Java SE version) and
> deprecate the InputStream-based method signatures.  In this case it
> would still be up to the implementation to support > 1 calls to
> Configuration#buildValidatorFactory(), unless the spec dictates (or
> better yet, provides) that naked InputStreams be wrapped in a
> DataSource implementation that caches their content.  Otherwise, I may
> have just argued the way to Configuration#buildValidatorFactory() not
> being available for multiple calls after all, in which case *this*
> should be formally declared.
>
> Matt
>
>> For example, Configuration is not a thread-safe object.
>>
>> Emmanuel
>>
>> On 19 mars 2012, at 17:21, Matt Benson wrote:
>>
>>> Hi Gunnar,
>>>  I agree that nothing is specified, and therefore that my default
>>> understanding would have been (and in fact was and is) that there is
>>> no reason a Configuration cannot be reused to build another
>>> ValidatorFactory.  The fact that Configuration and ConfigurationState
>>> are separate interfaces seems to imply this as well, albeit subtly.  I
>>> could believe there might be a use-case for building a number of
>>> ValidatorFactory instances, each with e.g. one configuration property
>>> modified from the last.
>>>
>>> $0.02,
>>> Matt
>>>
>>> On Sun, Mar 18, 2012 at 5:09 AM, Gunnar Morling
>>> <gunnar.morling at googlemail.com> wrote:
>>>> Hi all,
>>>>
>>>> based on a question in the HV user forum [1] I'm wondering whether
>>>> it's legal to invoke buildValidatorFactory() several times on the same
>>>> instance of javax.validation.Configuration:
>>>>
>>>> Configuration<?> configuration = Validation.byDefaultProvider().configure();
>>>>
>>>> //set up interpolator, traversable resolver etc.
>>>> configuration. ...();
>>>>
>>>> ValidatorFactory vf1 = configuration.buildValidatorFactory();
>>>>
>>>> //further customize configuration for another factory
>>>> configuration. ...();
>>>>
>>>> ValidatorFactory vf2 = configuration.buildValidatorFactory();
>>>>
>>>> I'm not sure how often one would do something like this in practice,
>>>> but I think we should make clear whether this is a valid use case or
>>>> whether a Configuration instance is to be thrown away after invoking
>>>> buildValidatorFactory().
>>>>
>>>> After having a look at the spec and the API documentation I think it's
>>>> currently unspecified. Any thoughts?
>>>>
>>>> Thanks,
>>>>
>>>> --Gunnar
>>>>
>>>> [1] https://forum.hibernate.org/viewtopic.php?f=9&t=1014788
>>>> _______________________________________________
>>>> beanvalidation-dev mailing list
>>>> beanvalidation-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>> _______________________________________________
>>> beanvalidation-dev mailing list
>>> beanvalidation-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>
>>
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev