Well JUL, the JDK logging API, is a piece of crap. I hate it. But it's what is available when you stay strictly in the bounds of the JDK.
One thing to look at it is how Xerces/Xalan handle this. I know I can endorse them without adding commons logging but I can also get slf4j/logback (and when I was using it, jcl/log4j) to suck up and print out logging messages for those libs. On Thu, Nov 3, 2011 at 10:02, Sean Mullan <[email protected]> wrote: > On 11/2/11 7:19 PM, Chad La Joie wrote: >> On Wed, Nov 2, 2011 at 18:13, Sean Mullan <[email protected]> wrote: >>> The JDK and Santuario implementations use different logging APIs. >> >> Right, that is the reason you have to put the commons logging library >> in the endorsed directory and the cause of the potential conflicts. >> The question is, is that really the way it should be? >> >> Personally, I think if the goal is to allow Santuario to be used as a >> JVM's JSR105 implementation, as opposed to just implementing the >> JSR105 APIs, then you have to accept the limitations of the JVM's >> environment (i.e., use their logging facility). > > I'm open to doing this, since it is the main integration pain point I have to > go > through every time I pull in a new release of Santuario into the JDK. I don't > see any advantage to keeping the commmons-logging dependency as the logging > API > in the JDK offers equivalent functionality for what we are using it for. > However, I have not thought enough about the compatibility impact so we should > think this through some more first. > > --Sean > -- Chad La Joie www.itumi.biz trusted identities, delivered
