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

[Matt Benson]

On Mon, Mar 26, 2012 at 3:47 PM, Matt Benson <gudnabrsam at gmail.com> wrote:
> On Mon, Mar 26, 2012 at 3:41 PM, Gunnar Morling
> <gunnar.morling at googlemail.com> wrote:
>> 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.

Good point, Gunnar.  For some reason I failed to think about the much
less expensive idea of simply calling #isMarkSupported() and wrapping
to a mark-supporting version, though e.g. using BufferedInputStream
this still requires that the length of the stream not exceed the mark
limit... :\

Matt

>>
>
> Good point, Gunnar.  For some reason I failed to think about the much
> less expensive idea of simply calling #isMarkSupported() and wrapping
> to a mark-supporting version, though e.g. using BufferedInputStream
> this still requires that the length of the stream not exceed the mark
> limit... :\
>
> Matt
>
>> --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
>>
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev