Re: [xsl] Somewhat off-topic question (isolating XLST engine) was Re: [xsl] Followup about Saxon-HE and Oracle Unified Directory (OUD) problem

["Michael Kay mike@xxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

One approach to this is to put your own implementation of the JAXP
TransformerFactory interface (in a JAR file with a suitable manifest) on the
classpath, ahead of Saxon in the search order; and when it is invoked,
explicitly call the Xalan implementation. In the part of the application that
needs to use Saxon, either instantiate Saxon's TransformerFactory
implementation directly, or use Saxon's own s9api API rather than using JAXP.

I'm sure there are other solutions that involve setting JAXP system
properties, but it may be difficult to identify a place where you are able to
set them.

The fact that OUD contains a JAXB component probably explains why you are
having the problem, but it doesn't provide a way to the solution.

Theoretically Java modules provide a solution to this kind of problem, but I
don't have any practical experience of building an application this way and I
can't offer any insights into whether or how it can be made to work.

Another approach, since you're using Saxon-HE, is to modify the JAR file to
remove the relevant manifest.

Michael Kay
Saxonica

> On 8 Sep 2023, at 13:30, Norm Tovey-Walsh ndw@xxxxxxxxxx
<xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> "ohaya ohaya@xxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> writes:
>> Sorry - per the subject this may be kind of off-topic for this list...
>
> Last time this came up, I thought Mike laid out a pretty convincing
> explanatin of the problem. You appear to have competing implementations
> of XSLT on the classpath. The JAXP interface (I am responsible for some
> of the errors in JAXP, but I think this one predates me!) doesnbt really
> give you good control over this.
>
> If youbve got both Xalan and Saxon on the classpath, youbre sometimes
> going to get odd behavior. If your code requires Saxon and some other
> code requires Xalan, I donbt know of any way to make it work reliably
> for both parties.
>
>> 1) In one of the responses I got from Oracle, they said the following:
>> "Also OUD ships a jaxb jar ./lib:jaxb-api-2.2.12 which may or may not
>> be helpful for you. ". I kind of ignored that comment/suggestion at
>> the time, but now, I am wondering, can we somehow leverage that
>> Oracle-produced jaxb jar, to allow us to use SAXON-HE together with
>> OUD?
>
> I donbt think thatbs going to help. JAXB is a different technology and
> no version of it on the classpath is going to have any impact on how
> Saxon and Xalan interfere with each other.
>
>> 2) Has anyone else run into a similar situation, and if so, is there
>> maybe some way to "isolate" the XLST engine/libraries so that it
>> doesn't cause the problems that I encountered when I tried to
>> integrate the SAXON-HE libs with OUD?
>
> I think you already implemented an entirely pragmatic solution: run the
> Saxon code in a different VM by way of a web service.
>
>                                        Be seeing you,
>                                          norm
>
> --
> Norm Tovey-Walsh <ndw@xxxxxxxxxx>
> https://norm.tovey-walsh.com/
>
>> Sometimes the only choices you have are bad ones, but you still have to
>> choose.--Dr Who