On Mar 26, 2012, at 10:48 PM, Matt Benson wrote:
On Mon, Mar 26, 2012 at 3:47 PM, Matt Benson
<gudnabrsam(a)gmail.com> wrote:
> On Mon, Mar 26, 2012 at 3:41 PM, Gunnar Morling
> <gunnar.morling(a)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... :\
I think using mark and reset is the best solution. I don't think we have to worry
about the length of the stream exceeding the mark limit. We are talking configuration
files after all. Via InputStream#mark(int readlimit) we can even set the limit to
something
like Integer.MAX_VALUE.
The question is whether we should wrap an input stream which does not support mark/reset
into a BufferedInputStream. I am tempted to say that it is the responsibility of the
client to provide
a buffered stream in case it wants to reuse the configuration. Of course the documentation
has to
be clear about this.
--Hardy