I would doubt if WSS4J works with this type of messages. We use DOM, XML-SEC uses DOM, and Xalan uses DOM too. Also during the processing of the message there is a need to perform cannonicalization. IMHO, the current c14n implementation requires to have the full document as DOM in memory.
I'm not a specialist in c14, but I can imagine that some c14n algorithms are not possible without having the doc in memory. I'm sure the c14n-insiders can answer this question. I crosspost this the the XML-SEC mailing list, because this is mainly a problem of security handling. Regards, Werner Davanum Srinivas wrote: > very interesting...what sort of hardware do you run this on currently? > we haven't tested this large messages. internally yes we use DOM. > Xerces does have some deferred load capabilities, depends on the jvm > performance as well. would be worth our time to try this out and see > if we can help you. let us know. If we see stuff that fails, am > positive we can get it fixed one way or another (since all components > in wss4j are open source as well) > > thanks, > dims > > On 8/31/05, Idan Miller <[EMAIL PROTECTED]> wrote: > >> >>Hi everyone, >> >>Our project uses web services to transfer XML messages that can be of a very >>large size (up to 100MB). >> >>Currently, we are using WSE over IIS for verifying the signing for incoming >>messages. Due to a problem with WSE loading the XML using a DOM Document >>(probably due to cannonization), combined with memory being held in the >>large object heap in .NET, we are unable to transfer very large messages, >>since we simply run out of memory that doesn't get released. >> >>Now that WSS4J is out, we would like to know if this problem will be solved >>by changing our architecture to use apache axis and WSS4J: >> >>How does WSS4J handle large messages? >>Does it use DOM or does it use a reader (SAX) for cannonization? >>Also, if it does use DOM, has it been tested for out of memory errors? >> >>p.s. we are using X509 certificates for the signing. >> >>Thanks, >>Idan. > > >