A silly question

[Berin Lautenbach <be...@ozemail.com.au>]

Axl/Erwin/Karel and anyone else ;>.

The XMLSignatureInput class and the ResourceResolverSpi classes all seem 
to take an InputStream and read the entire thing in to a byte array, 
which is then re-wrapped in an input stream and sent to the Signature class.

This appears to be so that the XMLSignature can be guaranteed of being 
able to call reset on the input stream.

I'm playing with the ResourceResolver classes for the XMLCipher stuff, 
and was wondering what the best way is to get around this.  I want to be 
able to process large encrypted files without having to read the whole 
thin in.

E.g. LocalFileSystem resolver returns the straight InputStream, which 
the XMLSignatureInput ctor immediately transforms to a byte array.  If 
that's a massive file, we have just used up most of our memory, but we 
can call reset on the InputStream.

The HTTP resolver (where I don't believe reset is possible??) already 
reads to a byte array which is then re-wrapped.  So that gets read again 
which is fairly inefficient.

So maybe we could update the XMLSignatureInput ctor to call 
markSupported on the input streams, and if it returns true just use it 
directly?  Otherwise copy to a byte[] and re-wrap.

Or is there a reason this can't be done?

(I think we could also wrap the HTTP class in a new InputStream class 
that would handle the reset, but that's another story :>).

Cheers,
	Berin

Re: A silly question

[Berin Lautenbach <be...@ozemail.com.au>]

Axl Mattheus wrote:

>> So maybe we could update the XMLSignatureInput ctor to call 
>> markSupported on the input streams, and if it returns true just use it 
>> directly?  Otherwise copy to a byte[] and re-wrap.
>>
>> Or is there a reason this can't be done?
> 
> 
> I can not think of a reason this cannot be done. I do not have any 
> information around the original design rational. That would have been 
> nice. Your thoughts on how to improve the situation seem logical.

I reckon we can look at this for the version post a fork, unless someone 
wants us to look at it sooner.

Cheers,
	Berin

Re: A silly question

[Axl Mattheus <Ax...@Sun.COM>]

Berin Lautenbach wrote:

> Axl/Erwin/Karel and anyone else ;>.
>
> The XMLSignatureInput class and the ResourceResolverSpi classes all 
> seem to take an InputStream and read the entire thing in to a byte 
> array, which is then re-wrapped in an input stream and sent to the 
> Signature class.
>
> This appears to be so that the XMLSignature can be guaranteed of being 
> able to call reset on the input stream.
>
> I'm playing with the ResourceResolver classes for the XMLCipher stuff, 
> and was wondering what the best way is to get around this.  I want to 
> be able to process large encrypted files without having to read the 
> whole thin in.
>
> E.g. LocalFileSystem resolver returns the straight InputStream, which 
> the XMLSignatureInput ctor immediately transforms to a byte array.  If 
> that's a massive file, we have just used up most of our memory, but we 
> can call reset on the InputStream.
>
> The HTTP resolver (where I don't believe reset is possible??) already 
> reads to a byte array which is then re-wrapped.  So that gets read 
> again which is fairly inefficient.
>
> So maybe we could update the XMLSignatureInput ctor to call 
> markSupported on the input streams, and if it returns true just use it 
> directly?  Otherwise copy to a byte[] and re-wrap.
>
> Or is there a reason this can't be done?

I can not think of a reason this cannot be done. I do not have any 
information around the original design rational. That would have been 
nice. Your thoughts on how to improve the situation seem logical.

>
> (I think we could also wrap the HTTP class in a new InputStream class 
> that would handle the reset, but that's another story :>).
>
> Cheers,
>     Berin
>
>