The JDK and Santuario implementations use different logging APIs. Part of the problem is also that the org.jcp.xml.dsig classes are named the same in the JDK and Santuario, so it loads the JDK classes first - we're planning on fixing this in the 1.5 release of Santuario by renaming these classes so they are distinct from the JDK.
In the meantime, you may be able to hack around this by creating a JCA provider for XMLDSig which loads the JSR 105 implementation SPI classes from xmlsec.jar. --Sean On 11/2/11 4:59 PM, Chad La Joie wrote: > This is pretty suboptimal. Classes (or JARs of classes) within the > endorsed directory are visible on the classpath and obviously logging > frameworks are one of those things where there is a lot of > variability. > > On Wed, Nov 2, 2011 at 12:50, Sean Mullan <[email protected]> wrote: >> On 11/2/11 12:40 PM, Chad La Joie wrote: >>> I've been planning to move our Shib code over to use the JSR105 APIs >>> for signature work. One of our testers today was trying to use SHA256 >>> within their signatures and received the error that this wasn't >>> supported by the JVM-shipped implementation of those APIs. So, I >>> figured we'd just endorse xmlsec in order to use it at the JVM's >>> JSR105 impl. >>> >>> However, when we tried this, we received the error that Apache >>> Common's Logging was not available. This, of course, is true. That >>> library isn't available in the JVM's internal classpath. >>> >>> So, the question is, should it be possible to use xmlsec as a JVM's >>> JSR105 implementation? >> >> Yes, but you need to also put commons-logging.jar in the endorsed dir. See my >> blog for more info: >> >> http://blogs.oracle.com/mullan/entry/using_more_recent_apache_xml >> >> --Sean >> > > >
