Re: Followup about Saxon-HE and Oracle Unified Directo

For reference the SO thread is here:

https://stackoverflow.com/questions/76971336/

>
> Michael has posted some comment on my SO topic, but I am still a little
puzzled about why just having Saxon-HE in the dependencies is causing the OUD
instance itself to fail to start, and also how, or even "if" it is possible to
get it to work?
>
...
>
> Comparing the above and what Michael has said on SO, I am wondering if I
added the Saxon-HE dependency back to the plugin code, but also added a line
to plugin code like:
>
> System.setProperty("javax.xml.transform.TransformerFactory",
"net.sf.saxon.TransformerFactoryImpl");
>
> Would THAT eliminate the problem and allow the OUD instance to start AND the
XSLT being used in the plugin to also work?
>

Sorry if I haven't managed to explain it to you (but I'm not sure that forking
the discussion to a different forum is going to be helpful).

Getting your own code to use Saxon isn't going to be a problem. You can either
instantiate the Saxon TransformerFactory explicitly (using `new
net.sf.saxon.TransformerFactoryImpl()`) or you can use Saxon's s9api interface
instead of JAXP.

Your challenge is to ensure that the code in OUD, over which you have no
control, DOESN'T use Saxon when you add Saxon to the classpath. It's a design
weakness of the JAXP API that when code calls
"TransformerFactory.newInstance()` it gets whatever XSLT engine it finds on
the classpath, and unless the application code was written to be completely
portable, that can cause a failure, which is almost certainly what is
happening in this case. For example, it will cause a failure if the stylesheet
that is invoked contains any Xalan extensions.

You definitely don't want to set the system property
"javax.xml.transform.TransformerFactory" to the Saxon TransformerFactory, you
want to set it to the TransformerFactory that OUD is expecting to use
internally, which is probably Xalan.

Without knowing OUD, it's impossible to say whether setting the system
property from the plugin is going to set it early enough to have any effect.
The safest way would be to set it using the -D option on the command line at
the time the Java VM is initialized.

Michael Kay
Saxonica