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

[Hardy Ferentschik]

>>> There was indeed an issue with building multiple ValidatorFactory instances from a single
>>> Configuration instance (at least in Hibernate Validator). However, we found a way to solve this, by
>>> checking whether the provided InputStream supports marking [2]. If it does than there is no problem and if it doesn't
>>> we wrap the stream in a BufferedInputStream which does. Once you have a markable stream you can mark, read
>>> and finally reset it [3]. This way you can reuse the Configuration multiple times.
>>> 
>> 
>> Yes, I think I remember discussing this--not perfect, but serviceable.
>> Of course, if Bean Validation v1.1 were to move up to Java SE 6,
>> javax.activation.DataSource might possibly be more appropriate as an
>> intermediate type to *provide* an InputStream any number of times.
>> Thoughts?
> 
> While discussing an issue with the spec JAR
> (https://hibernate.onjira.com/browse/BVAL-298), Emmanuel agreed on
> basing BV 1.1 on SE 6 (see
> https://hibernate.onjira.com/browse/BVAL-299).

Right. We can definitely assume Java 6.

> That said, I think j.a.DataSource indeed looks nice and I think it
> would have been great if it could have been used in BV 1.0. But
> introducing it now AFAICS basically means adding an overloaded method
> like Configuration#addMapping(DataSource dataSource). As users might
> still use the old method passing an input stream, we need to address
> BVAL-282 anyways in order to make a configuration re-usable. But then
> there is no much advantage by supporting j.a.DataSource IMO.

+1 If we would start from scratch a DataSource would be the better choice to provide mapping data.
However, as Gunnar is saying we are basically stuck with the existing Configuration#addMapping().
I don't think we gain anything by adding an overloaded version using DataSource.


--Hardy