Re: Somewhat off-topic question (isolating XLST engine

"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

[demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]