>> 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 . 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 . This way you can reuse the Configuration multiple
> 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.
While discussing an issue with the spec JAR
), Emmanuel agreed on
basing BV 1.1 on SE 6 (see
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
However, as Gunnar is saying we are basically stuck with the existing
I don't think we gain anything by adding an overloaded version using DataSource.