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(a)apache.org>:
On Thu, Mar 22, 2012 at 10:32 AM, Emmanuel Bernard
<emmanuel(a)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(a)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(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev