(c14n killer) Re: OUT OF MEMORY Exception, is it posible to sing a big XML ????

[Martin Labarthe Dubois <du...@consist.com.ar>]

> The killer is the c14n. For our use we don't actually need full-c14n, we
just need to be sure that the hash we get when the > > document is sent will
be the same as that when it's received, despite having passed through one or
more XML processors. > We could have used compression (basically turn the
XML into binary that the intermediate processors couldn't/wouldn't >mess
with) but decided in the end not to.

Is there something wrong with

org.apache.xml.security.utils.XMLUtils.outputDOMc14nWithComments()

because it doesn´t consume so so much memory .....

Re: (c14n killer) Re: OUT OF MEMORY Exception, is it posible to sing a big XML ????

["raul-info@r-bg.com" <ra...@r-bg.com>]

Martin Labarthe Dubois wrote:

>>The killer is the c14n. For our use we don't actually need full-c14n, we
>>    
>>
>just need to be sure that the hash we get when the > > document is sent will
>be the same as that when it's received, despite having passed through one or
>more XML processors. > We could have used compression (basically turn the
>XML into binary that the intermediate processors couldn't/wouldn't >mess
>with) but decided in the end not to.
>
>Is there something wrong with
>
>org.apache.xml.security.utils.XMLUtils.outputDOMc14nWithComments()
>
>because it doesn´t consume so so much memory .....
>
>
>  
>
The problem with all c14n implementations is that they relay in 
CircumventBug2650 this function basicaly copies all xmlns attributes in 
all nodes, and does consume a lot. Then the c14n object relays in this 
information.

I have created a version of c14nExcl does not used this. But i'm still 
testing it. In trees whithout the Circu...Bug2650 passed is much faster, 
but is really slow with trees that have passed it. When I have this 
fixed i'll send a patch in case somebody wants to test it.

Regards,

Raul