Selecting Xalan implementations under Eclipse

[Joseph Kessselman <ke...@alum.mit.edu>]

Just in case anyone else has forgotten, the simplest solution for making 
sure we're debugging the right code appears to be to set the environment 
property:

javax.xml.transform.TransformerFactory=org/apache/xalan/processor/TransformerFactoryImpl

Otherwise it may default to loading the 
com.sun.org.apache.xalan.internal version from rt.jar.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xalan.apache.org
For additional commands, e-mail: dev-help@xalan.apache.org

Re: Selecting Xalan implementations under Eclipse

[Joseph Kessselman <ke...@alum.mit.edu>]

Found a good solution: Modify the xalan-test's invocation of 
ResultScanner to use bootclasspath to make sure we're running our 
version of the code rather than risking a mixture of ours and whatever 
the JRE's TransformerFactory configuration defaults to. We were already 
doing that in the tests themselves, so this is just making the scan 
consistent with those other operations.

I've confirmed that this doesn't harm testing the Ant build, but does 
fix the issue when testing the Maven build.

Fix has been merged into xalan-test.


With this fix in place, it *MAY* be time to start thinking about 
squashing my xalan-java-mvn branch and issuing a pull request for 
official review.


Of course longer term we probably want to move xalan-test into the test 
trees of the maven build, so continuous integration can smoketest. But 
that can be done as a subsequent pass; I haven't looked at how much 
hassle adapting the test drivers (currently written as Ant tasks) will be.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xalan.apache.org
For additional commands, e-mail: dev-help@xalan.apache.org

Re: Selecting Xalan implementations under Eclipse

[Joseph Kessselman <ke...@alum.mit.edu>]

Or, perhaps more effective, set it in jre/lib/jaxp.properties. (And of 
course change those / characters to .; sorry I didn't fix that before 
sending.)

FWIW: When I do so, I am able to run the ResultScanner's FailScanner.xsl 
from Eclipse without trouble, whereas before it gave me the error I've 
been seeing from the command line. That's suitably odd.

Best guess I have is the Ant build's invocation of ResultScanner was 
running into an incompatibility between the "internal" Xalan code 
shipped with the JRE and our Ant build. So next step is to see if I can 
convince the Ant/CLI invocation to run the ResultScan, as well as the 
tests, entirely from our version of Xalan.

... and perhaps to check that the tests really *have* been running 
against our build rather than the JRE's. Though I think that the fact 
that we're seeing different results from my jarfiles and the ant-built 
ones does suggest that the tests themselves were Doing The Right Thing.

Yay.



On 10/12/2023 4:04 PM, Joseph Kessselman wrote:
> Just in case anyone else has forgotten, the simplest solution for making 
> sure we're debugging the right code appears to be to set the environment 
> property:
> 
> javax.xml.transform.TransformerFactory=org/apache/xalan/processor/TransformerFactoryImpl
> 
> Otherwise it may default to loading the 
> com.sun.org.apache.xalan.internal version from rt.jar.
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xalan.apache.org
For additional commands, e-mail: dev-help@xalan.apache.org