Raul wrote: > It seems that > the patch slows the test a little(<5%) I don't know how big > the impact > is when using in real world examples(I don't think it will be > too much, > but if anyone can post his own results we can check for sure). > It will be great if it can be test as wild as possible as > there some big > changes in it. I just ran the full test suite for xml-security off the latest cvs. I do not have reference for the run time before... Tell me if you want my logs.
test target ======== I had one error at the end from junitreport after running the test target [junitreport] The file C:\dev\workspace\xml-security\build\docs\xml\junit\TEST-org.apache.xml.s ecurity.test.encryption.XMLCipherTester.xml is not a valid XML document. It is possibly corrupted. That file is just empty. I just ignored that and kept trucking. test_exc_c14n target ======== Junit not being in the libs dir in CVS, the build failed.... I added it, and it ran fine, and I kept trucking. test_xenc target ========= Failed, with some No Class found, but I probbaly do not have the right JCE/crypto config, off a vanilla 1.42_05 JDK Did not have the time to dig further. I just ignored it and I kept trucking.... I then ran a dist, and ran the full test suite on our nexb project. They ran fine, including our perfs tests, so whatever changes you made are not seen on our side speed wise. But keep in mind that we are using mostly c14 and exclusive c14n for now. By the way, it would nice ass you are releasing a new version if you were to adopt the convention of putting the release version in the Jar names. ie xml-security-1.1.0.jar is much better than xmlsec.jar I got bitten by that more than once.... Ever since I always keep religiously track of all my jars versions... Doing it for the depdendent jars you distribute is also always a good idea. It helps escape the Jar Hell! -- Cheers Philippe philippe ombredanne | nexB - Open IT Asset Management 1 650 799 0949 | pombredanne at nexb.com http://www.nexb.com
