dmatej opened a new pull request, #101: URL: https://github.com/apache/santuario-xml-security-java/pull/101
In the beginning was this innocent issue: https://github.com/eclipse-ee4j/glassfish/issues/24138 Then we have found that the XmlSec is to blame. Then I have found that I don't like it's state - I had a suspiction about memory leaks, etc. So I did this ... ### Changes in Artifact - Updated dependencies - JDK11 instead of JDK8 - that's why I changed the major version. - If anyone wants to continue with JDK8 version, he can continue with maintenance in a new branch. But we need bigger progress. - System.Logger instead of SLF4J - Allows to use SLF4J2/LOG4J2/JUL/GJULE/Any Custom logging framework. - No mandatory dependency required - Added module-info.java - That's why I tested it in action with the GlassFish and TCK10 - AutoCloseable - Just for several types - I have found some old discussion about it, but based on obsoleted opinions. Currently not having it was contraproductive and was asking for leaks (I was able to produce some, but not with GF, just in xmlsec unit tests). - Split XmlSignatureInput to several standalone classes based on the type of input data. - I still don't think it is alright, but it is still much better than original "god object" - XmlSignatureStreamInput IS AutoCloseable. And still can cause leaks. But changing it would mean much larger changes. At least this type is standalone and specific. Implementation also allows to use custom closeable objects. - Added some XmlUtil methods for simple work with File+Path+Stream, buffers - Javadocs, formatting ### Changes in Tests - PMD now tests the tests too - All issues resolved - Especially many resource leaks (200?) - Performance tests moved to maven failsafe plugin and refactored to JMH+JUnit5 - Originally excluded - Disabled by default, use -DskipIT=false to enable them - Locally passed, however someone should analyze decryptDOM, after it ends there's still heap used, but I couldn't find why. - With more changes the performance improved, especially with bigger buffers and NIO. - Usage of Shenandoah GC - it is more aggressive, stats should be real or close to real at least - Proven that StAX is much faster than DOM. - Tests results: watch statistics, if the repeating is slower and slower, there's probably some leak (now it probably isn't). Junit tests just basic criteria. - Fixed JaCoCo configuration. ### Consequences - It would be good to release at least milestone after some time, so we could use it in MetroWSIT and Glassfish. Required changes are already prepared, it is quite easy and even better, WSIT will not need to repackage xmlsec, GF will not need SLF4J1 in dependencies, everything is more simple and clean. - Jetty doesn't complain any more in xmlsec tests - If some company would like to invest to xmlsec refactoring, it would be great ;-) - TCK tests results are here: https://ci.eclipse.org/jakartaee-tck/job/jakartaee-tck/job/10.0.x/29/testReport/ If I would remember yet something, I will add it here later ... -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
