0

We are working on a plugin for the Oracle's Oracle Unified Directory (OUD) product, and in this case, we needed to add support for XSLT in Java. So I tried adding SAXON-HE 11_5 as a Maven dependency and the plugin built ok in Eclipse.

However, when I tried to deploy the updated plugin JAR to the OUD (OUD Proxy) instance, the instance failed to start.

I've been chasing this problem (the OUD not starting) for a few days, then just noticed that the size of the JAR almost doubled at a certain point and then I realized that was when I added (NOTE: JUST added - I did not actually use the XSLT yet) the Saxon-HE 11_5 as dependency in the pom.xml.

So this morning, I removed the Saxon-HE 11_5 from the pom.xml and rebuilt the plugin and deployed the JAR, and now the OUD instance starts!!

The errors I was seeing when the Saxon-HE was a dependency during the OUD startup seemed just kind of UNrelated to anything. The errors seemed to revolve around a PIN being missing (OUD uses PINs to secure some JKS files I think). I didn't (and Oracle support didn't either) see any other errors in the logs), so it kind really kind of puzzling why JUST ADDING SAXON-HE as a Maven dependency would cause the plugin to cause OUD to fail to start?

We would REALLY like to be able to get the XSLT functionality, so I am hoping someone here might have an idea about this?

Thanks in advance, Jim

user555303
  • 1,146
  • 3
  • 20
  • 44

1 Answers1

0

Typically the problem is that the application invokes TransformerFactory.newInstance() to get an XSLT transformer. This is defined to return whatever XSLT transformation engine is found first on the classpath. When an application uses this mechanism, it ought to make sure that it will work with any conformant XSLT processor, but unfortunately this is not always the case, and applications sometimes have a dependency on a specific processor, typically Xalan (although it could, for example, be a dependency on Oracle's old XDK processor).

You can get diagnostics to reveal whether this is the problem by setting the Java system property jaxp.debug to 1.

You can force Xalan to be used as the default XSLT processor by setting the system property javax.xml.transform.TransformerFactory=org.apache.xalan.processor.TransformerFactoryImpl. This is the Apache version of Xalan. For the embedded JDK version of Xalan you traditionally set the property to "com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl" but I'm not sure if this still works now that dynamic loading of internal classes is prohibited.

See also Java/Maven - Saxon without SeviceLoader override and many other questions findable using a search for TransformerFactory Saxon Xalan.

Michael Kay
  • 156,231
  • 11
  • 92
  • 164
  • hi mIchael - I want to point out that I don't have any code at all yet to do anything with the Saxon-HE. All I did was add the to the pom.xml and then do a build in eclipse then put the JAR into the oud lib directory and start the oud instance. Would doing just that (and nothing else) cause the oud instance to fail to start? – user555303 Aug 24 '23 at 17:51
  • Yes, that would be precisely the effect if the OUD product is calling `TransformerFactory.newInstance()` and is expecting this to load Xalan. – Michael Kay Aug 24 '23 at 20:12
  • But why would it (OUD) be calling TransformerFactory.newInstance(), since I haven't included anything in my code to do any transformations? – user555303 Aug 24 '23 at 20:40
  • I've no idea what OUD does, but if it fails when you add Saxon to the classpath, then that's a very strong indication that it contains some XSLT code. Only someone who knows the internals of OUD can confirm that for certain. – Michael Kay Aug 25 '23 at 16:46