The opcgen 3M is extremely memory hungry. One of the iterations uses
over 400M (for C++) just to parse the document - so once you start
transforming etc. the memory utilisation can go through the roof. That
was one of the optimisations in the C library - to look at how to
significantly reduce
Raul Benito wrote:
If you think so... Then I will also do it in CVS head.
Anyway can you send a test case?
I can write one but I do know of a scenario when it can be seen.
If you try to verify a signature after a decryption operation has been
performed on the same document, this problem can b
I am planning to do the 1,3 release of the java xml security. The
changelog so far of the release is stated below:
But I want to concentrate in bugfixes for the time is left till the release.
So if anyhow has any bug that isn't fixed or any one not new
reported... You know send an email(or write
It sounds good. I will try to writte a test that stress this problem
with your suggestions,
Do you mind to fill a bugreport? or if you want i can do for you?
Regards,
On 7/26/05, Vishal Mahajan <[EMAIL PROTECTED]> wrote:
> Raul Benito wrote:
>
> >If you think so... Then I will also do it in CVS
Raul, Vishal,
in the WSS4J project we use the xml-sec java lib and
we discovered a similar problem about more than a year
ago with the same setup: Verifying a part of a document
after decryption. We solved that problem somehow :-). As
far as I can remember the fix was done in the encryption and
de
