On Mon, Mar 26, 2012 at 3:41 PM, Gunnar Morling <gunnar.morling(a)googlemail.com&gt; 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 > --Gunnar > > > 2012/3/26 Matt Benson <mbenson(a)apache.org&gt;: >> On Thu, Mar 22, 2012 at 10:32 AM, Emmanuel Bernard >> <emmanuel(a)hibernate.org&gt; 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&gt; 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 > > _______________________________________________ > beanvalidation-dev mailing list > beanvalidation-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/beanvalidation-dev