Re: [xsl] Followup about Saxon-HE and Oracle Unified Directory (OUD) problem

["ohaya ohaya@xxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

 Hi Michael.

I've asked Oracle to ask their dev team what they are expecting and also whether there is a way to pass system properties (including the jaxb.debug one) through to the plugin code.

Also I tried both the settings you mentioned in one of your SO responses:

"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."

with small Java app using the same Java version as the OUD and plugin use, and neither of those work (the errors from one of them look like when I tried the XSLT with one that doesn't support XSLT 2.0)

I am willing to try to build the plugin with the following in the plugin code:

System.setProperty("javax.xml.transform.TransformerFactory", "net.sf.saxon.TransformerFactoryImpl");

to see if that would allow the OUD to start. Do you think testing that would be helpful at all?


Thanks,
Jim
     On Thursday, August 24, 2023 at 05:50:46 PM EDT, Michael Kay <mike@xxxxxxxxxxxx> wrote:  
 
 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