ok, Evaluating my current code, I got the feeling that BouncyCastle is only required because some internal classes are using it as default implementation.
Paulo suggested me to adopt an older version in order to rid off BouncyCastle dependency from my current release. questions: - How deep is the coupling between iText and BouncyCastle? - Does it make sense to rid off Bouncy as default implementation and to create a more flexible design in order to keep the third party users to decide when to adopt Bouncy or not ? - what kind of digital certificate I will be unapt to use without bouncy? It seems the new version of JSSE is already useful for PKCS12 and self signed stuff, I don't know about more advanced features like Smart Card - and perhaps I am just asking naive :) In footprint I am using reflection to instantiate the worker classes, even using reflection to instantiate some classes included in my distribution jars. I am adopting this strategy to allow the adopters to include a external JAR in the classpath and ask the system to instantiate classes not included in the default distribution. This can seems weird at first sight, but allow me a loose coupling between footprint and third party libraries. The only strong coupling of footprint is with iText :) ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ iText-questions mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/itext-questions Buy the iText book: http://itext.ugent.be/itext-in-action/
