Xalan override issue?

[starksm64]

I looked at the xalan override test created for this issue:
http://jira.jboss.com/jira/browse/JBAS-2073

j2sdk1.4.2:

2005-09-06 19:48:01,115 INFO [ScopedXalanUnitTestCase] +++ testScopedXalanDeployment
2005-09-06 19:48:01,161 INFO [ScopedXalanUnitTestCase] ***XalanCheckDefault***
2005-09-06 19:48:01,161 INFO [ScopedXalanUnitTestCase] version.xerces1=not-present
2005-09-06 19:48:01,161 INFO [ScopedXalanUnitTestCase] java.ext.dirs=C:\usr\java\j2sdk1.4.2_06\jre\lib\ext
2005-09-06 19:48:01,161 INFO [ScopedXalanUnitTestCase] foundclasses.java.class.path=[]
2005-09-06 19:48:01,161 INFO [ScopedXalanUnitTestCase] version.DOM=2.0
2005-09-06 19:48:01,161 INFO [ScopedXalanUnitTestCase] java.version=1.4.2_06
2005-09-06 19:48:01,161 INFO [ScopedXalanUnitTestCase] version.xalan2_2=Xalan Java 2.7.0
2005-09-06 19:48:01,161 INFO [ScopedXalanUnitTestCase] foundclasses.sun.boot.class.path=[{serializer.jar-path=C:\cvs\JBoss4.0\jboss-4.0\build\output\jboss-4.0.3RC2\lib\endorsed\serializer.jar, serializer.jar-apparent.version=serializer.jar present-unknown-version}, {xalan.jar-path=C:\cvs\JBoss4.0\jboss-4.0\build\output\jboss-4.0.3RC2\lib\endorsed\xalan.jar}, {xercesImpl.jar-path=C:\cvs\JBoss4.0\jboss-4.0\build\output\jboss-4.0.3RC2\lib\endorsed\xercesImpl.jar, xercesImpl.jar-apparent.version=xercesImpl.jar from Xerces-J-bin.2.7.1}, {xml-apis.jar-path=C:\cvs\JBoss4.0\jboss-4.0\build\output\jboss-4.0.3RC2\lib\endorsed\xml-apis.jar, xml-apis.jar-apparent.version=xml-apis.jar from head branch of xml-commons, tag: xml-commons-external_1_3_02}]
2005-09-06 19:48:01,161 INFO [ScopedXalanUnitTestCase] version.crimson=present-unknown-version
2005-09-06 19:48:01,161 INFO [ScopedXalanUnitTestCase] version.xalan1=not-present
2005-09-06 19:48:01,161 INFO [ScopedXalanUnitTestCase] java.class.path=C:\cvs\JBoss4.0\jboss-4.0\build\output\jboss-4.0.3RC2\bin\run.jar;C:\usr\java\j2sdk1.4.2_06\lib\tools.jar
2005-09-06 19:48:01,161 INFO [ScopedXalanUnitTestCase] sun.boot.class.path=C:\cvs\JBoss4.0\jboss-4.0\build\output\jboss-4.0.3RC2\lib\endorsed\resolver.jar;C:\cvs\JBoss4.0\jboss-4.0\build\output\jboss-4.0.3RC2\lib\endorsed\serializer.jar;C:\cvs\JBoss4.0\jboss-4.0\build\output\jboss-4.0.3RC2\lib\endorsed\xalan.jar;C:\cvs\JBoss4.0\jboss-4.0\build\output\jboss-4.0.3RC2\lib\endorsed\xercesImpl.jar;C:\cvs\JBoss4.0\jboss-4.0\build\output\jboss-4.0.3RC2\lib\endorsed\xml-apis.jar;C:\usr\java\j2sdk1.4.2_06\jre\lib\rt.jar;C:\usr\java\j2sdk1.4.2_06\jre\lib\i18n.jar;C:\usr\java\j2sdk1.4.2_06\jre\lib\sunrsasign.jar;C:\usr\java\j2sdk1.4.2_06\jre\lib\jsse.jar;C:\usr\java\j2sdk1.4.2_06\jre\lib\jce.jar;C:\usr\java\j2sdk1.4.2_06\jre\lib\charsets.jar;C:\usr\java\j2sdk1.4.2_06\jre\classes
2005-09-06 19:48:01,161 INFO [ScopedXalanUnitTestCase] foundclasses.java.ext.dirs=[]
2005-09-06 19:48:01,161 INFO [ScopedXalanUnitTestCase] version.JAXP=1.1 or higher
2005-09-06 19:48:01,161 INFO [ScopedXalanUnitTestCase] version.DOM.draftlevel=2.0fd
2005-09-06 19:48:01,161 INFO [ScopedXalanUnitTestCase] version.SAX=2.0
2005-09-06 19:48:01,161 INFO [ScopedXalanUnitTestCase] version.ant=not-present
2005-09-06 19:48:01,161 INFO [ScopedXalanUnitTestCase] version.xalan2x=Xalan Java 2.7.0
2005-09-06 19:48:01,161 INFO [ScopedXalanUnitTestCase] version.xerces2=Xerces-J 2.7.1
2005-09-06 19:48:01,411 INFO [ScopedXalanUnitTestCase] ***XalanCheckScoped***
2005-09-06 19:48:01,411 INFO [ScopedXalanUnitTestCase] version.xerces1=not-present
2005-09-06 19:48:01,411 INFO [ScopedXalanUnitTestCase] java.ext.dirs=C:\usr\java\j2sdk1.4.2_06\jre\lib\ext
2005-09-06 19:48:01,411 INFO [ScopedXalanUnitTestCase] foundclasses.java.class.path=[]
2005-09-06 19:48:01,411 INFO [ScopedXalanUnitTestCase] version.DOM=2.0
2005-09-06 19:48:01,411 INFO [ScopedXalanUnitTestCase] java.version=1.4.2_06
2005-09-06 19:48:01,411 INFO [ScopedXalanUnitTestCase] version.xalan2_2=Xalan Java 2.5.2
2005-09-06 19:48:01,411 INFO [ScopedXalanUnitTestCase] foundclasses.sun.boot.class.path=[{xalan.jar-path=C:\cvs\JBoss4.0\jboss-4.0\build\output\jboss-4.0.3RC2\lib\endorsed\xalan.jar}, {xercesImpl.jar-path=C:\cvs\JBoss4.0\jboss-4.0\build\output\jboss-4.0.3RC2\lib\endorsed\xercesImpl.jar, xercesImpl.jar-apparent.version=xercesImpl.jar WARNING.present-unknown-version}, {xml-apis.jar-path=C:\cvs\JBoss4.0\jboss-4.0\build\output\jboss-4.0.3RC2\lib\endorsed\xml-apis.jar, xml-apis.jar-apparent.version=xml-apis.jar present-unknown-version}]
2005-09-06 19:48:01,411 INFO [ScopedXalanUnitTestCase] version.crimson=present-unknown-version
2005-09-06 19:48:01,411 INFO [ScopedXalanUnitTestCase] version.xalan1=not-present
2005-09-06 19:48:01,411 INFO [ScopedXalanUnitTestCase] java.class.path=C:\cvs\JBoss4.0\jboss-4.0\build\output\jboss-4.0.3RC2\bin\run.jar;C:\usr\java\j2sdk1.4.2_06\lib\tools.jar
2005-09-06 19:48:01,411 INFO [ScopedXalanUnitTestCase] sun.boot.class.path=C:\cvs\JBoss4.0\jboss-4.0\build\output\jboss-4.0.3RC2\lib\endorsed\resolver.jar;C:\cvs\JBoss4.0\jboss-4.0\build\output\jboss-4.0.3RC2\lib\endorsed\serializer.jar;C:\cvs\JBoss4.0\jboss-4.0\build\output\jboss-4.0.3RC2\lib\endorsed\xalan.jar;C:\cvs\JBoss4.0\jboss-4.0\build\output\jboss-4.0.3RC2\lib\endorsed\xercesImpl.jar;C:\cvs\JBoss4.0\jboss-4.0\build\output\jboss-4.0.3RC2\lib\endorsed\xml-apis.jar;C:\usr\java\j2sdk1.4.2_06\jre\lib\rt.jar;C:\usr\java\j2sdk1.4.2_06\jre\lib\i18n.jar;C:\usr\java\j2sdk1.4.2_06\jre\lib\sunrsasign.jar;C:\usr\java\j2sdk1.4.2_06\jre\lib\jsse.jar;C:\usr\java\j2sdk1.4.2_06\jre\lib\jce.jar;C:\usr\java\j2sdk1.4.2_06\jre\lib\charsets.jar;C:\usr\java\j2sdk1.4.2_06\jre\classes
2005-09-06 19:48:01,411 INFO [ScopedXalanUnitTestCase] foundclasses.java.ext.dirs=[]
2005-09-06 19:48:01,411 INFO [ScopedXalanUnitTestCase] version.JAXP=1.1 or higher
2005-09-06 19:48:01,411 INFO [ScopedXalanUnitTestCase] version.DOM.draftlevel=2.0fd
2005-09-06 19:48:01,411 INFO [ScopedXalanUnitTestCase] version.SAX=2.0
2005-09-06 19:48:01,411 INFO [ScopedXalanUnitTestCase] version.ant=not-present
2005-09-06 19:48:01,411 INFO [ScopedXalanUnitTestCase] version.xalan2x=Xalan Java 2.5.2
2005-09-06 19:48:01,411 INFO [ScopedXalanUnitTestCase] version.xerces2=Xerces-J 2.7.1
2005-09-06 19:48:01,411 INFO [ScopedXalanUnitTestCase] *******************************************************
2005-09-06 19:48:01,411 INFO [ScopedXalanUnitTestCase] Default deployment uses xalan version: Xalan Java 2.7.0
2005-09-06 19:48:01,411 INFO [ScopedXalanUnitTestCase] Scoped deployment uses xalan version : Xalan Java 2.5.2
2005-09-06 19:48:01,411 INFO [ScopedXalanUnitTestCase] *******************************************************

jdk1.5.0:

2005-09-06 19:57:52,224 INFO [ScopedXalanUnitTestCase] +++ testScopedXalanDeployment
2005-09-06 19:57:52,318 INFO [ScopedXalanUnitTestCase] ***XalanCheckDefault***
2005-09-06 19:57:52,318 INFO [ScopedXalanUnitTestCase] version.xerces1=not-present
2005-09-06 19:57:52,318 INFO [ScopedXalanUnitTestCase] java.ext.dirs=C:\usr\java\jdk1.5.0_04\jre\lib\ext
2005-09-06 19:57:52,318 INFO [ScopedXalanUnitTestCase] foundclasses.java.class.path=[]
2005-09-06 19:57:52,318 INFO [ScopedXalanUnitTestCase] version.DOM=2.0
2005-09-06 19:57:52,318 INFO [ScopedXalanUnitTestCase] java.version=1.5.0_04
2005-09-06 19:57:52,318 INFO [ScopedXalanUnitTestCase] version.xalan2_2=Xalan Java 2.7.0
2005-09-06 19:57:52,318 INFO [ScopedXalanUnitTestCase] foundclasses.sun.boot.class.path=[{serializer.jar-path=C:\cvs\JBoss4.0\jboss-4.0\build\output\jboss-4.0.3RC2\lib\endorsed\serializer.jar, serializer.jar-apparent.version=serializer.jar present-unknown-version}, {xalan.jar-path=C:\cvs\JBoss4.0\jboss-4.0\build\output\jboss-4.0.3RC2\lib\endorsed\xalan.jar}, {xercesImpl.jar-path=C:\cvs\JBoss4.0\jboss-4.0\build\output\jboss-4.0.3RC2\lib\endorsed\xercesImpl.jar, xercesImpl.jar-apparent.version=xercesImpl.jar from Xerces-J-bin.2.7.1}, {xml-apis.jar-path=C:\cvs\JBoss4.0\jboss-4.0\build\output\jboss-4.0.3RC2\lib\endorsed\xml-apis.jar, xml-apis.jar-apparent.version=xml-apis.jar from head branch of xml-commons, tag: xml-commons-external_1_3_02}]
2005-09-06 19:57:52,318 INFO [ScopedXalanUnitTestCase] version.crimson=not-present
2005-09-06 19:57:52,318 INFO [ScopedXalanUnitTestCase] version.xalan1=not-present
2005-09-06 19:57:52,318 INFO [ScopedXalanUnitTestCase] java.class.path=C:\cvs\JBoss4.0\jboss-4.0\build\output\jboss-4.0.3RC2\bin\run.jar;C:\usr\java\jdk1.5.0_04\lib\tools.jar
2005-09-06 19:57:52,318 INFO [ScopedXalanUnitTestCase] sun.boot.class.path=C:\cvs\JBoss4.0\jboss-4.0\build\output\jboss-4.0.3RC2\lib\endorsed\resolver.jar;C:\cvs\JBoss4.0\jboss-4.0\build\output\jboss-4.0.3RC2\lib\endorsed\serializer.jar;C:\cvs\JBoss4.0\jboss-4.0\build\output\jboss-4.0.3RC2\lib\endorsed\xalan.jar;C:\cvs\JBoss4.0\jboss-4.0\build\output\jboss-4.0.3RC2\lib\endorsed\xercesImpl.jar;C:\cvs\JBoss4.0\jboss-4.0\build\output\jboss-4.0.3RC2\lib\endorsed\xml-apis.jar;C:\usr\java\jdk1.5.0_04\jre\lib\rt.jar;C:\usr\java\jdk1.5.0_04\jre\lib\i18n.jar;C:\usr\java\jdk1.5.0_04\jre\lib\sunrsasign.jar;C:\usr\java\jdk1.5.0_04\jre\lib\jsse.jar;C:\usr\java\jdk1.5.0_04\jre\lib\jce.jar;C:\usr\java\jdk1.5.0_04\jre\lib\charsets.jar;C:\usr\java\jdk1.5.0_04\jre\classes
2005-09-06 19:57:52,318 INFO [ScopedXalanUnitTestCase] foundclasses.java.ext.dirs=[]
2005-09-06 19:57:52,318 INFO [ScopedXalanUnitTestCase] version.JAXP=1.1 or higher
2005-09-06 19:57:52,318 INFO [ScopedXalanUnitTestCase] version.DOM.draftlevel=2.0fd
2005-09-06 19:57:52,318 INFO [ScopedXalanUnitTestCase] version.SAX=2.0
2005-09-06 19:57:52,318 INFO [ScopedXalanUnitTestCase] version.ant=not-present
2005-09-06 19:57:52,318 INFO [ScopedXalanUnitTestCase] version.xalan2x=Xalan Java 2.7.0
2005-09-06 19:57:52,318 INFO [ScopedXalanUnitTestCase] version.xerces2=Xerces-J 2.7.1
2005-09-06 19:57:52,427 INFO [ScopedXalanUnitTestCase] ***XalanCheckScoped***
2005-09-06 19:57:52,427 INFO [ScopedXalanUnitTestCase] version.xerces1=not-present
2005-09-06 19:57:52,427 INFO [ScopedXalanUnitTestCase] java.ext.dirs=C:\usr\java\jdk1.5.0_04\jre\lib\ext
2005-09-06 19:57:52,427 INFO [ScopedXalanUnitTestCase] foundclasses.java.class.path=[]
2005-09-06 19:57:52,427 INFO [ScopedXalanUnitTestCase] version.DOM=2.0
2005-09-06 19:57:52,427 INFO [ScopedXalanUnitTestCase] java.version=1.5.0_04
2005-09-06 19:57:52,427 INFO [ScopedXalanUnitTestCase] version.xalan2_2=Xalan Java 2.5.2
2005-09-06 19:57:52,427 INFO [ScopedXalanUnitTestCase] foundclasses.sun.boot.class.path=[{xalan.jar-path=C:\cvs\JBoss4.0\jboss-4.0\build\output\jboss-4.0.3RC2\lib\endorsed\xalan.jar}, {xercesImpl.jar-path=C:\cvs\JBoss4.0\jboss-4.0\build\output\jboss-4.0.3RC2\lib\endorsed\xercesImpl.jar, xercesImpl.jar-apparent.version=xercesImpl.jar WARNING.present-unknown-version}, {xml-apis.jar-path=C:\cvs\JBoss4.0\jboss-4.0\build\output\jboss-4.0.3RC2\lib\endorsed\xml-apis.jar, xml-apis.jar-apparent.version=xml-apis.jar present-unknown-version}]
2005-09-06 19:57:52,427 INFO [ScopedXalanUnitTestCase] version.crimson=not-present
2005-09-06 19:57:52,427 INFO [ScopedXalanUnitTestCase] version.xalan1=not-present
2005-09-06 19:57:52,427 INFO [ScopedXalanUnitTestCase] java.class.path=C:\cvs\JBoss4.0\jboss-4.0\build\output\jboss-4.0.3RC2\bin\run.jar;C:\usr\java\jdk1.5.0_04\lib\tools.jar
2005-09-06 19:57:52,427 INFO [ScopedXalanUnitTestCase] sun.boot.class.path=C:\cvs\JBoss4.0\jboss-4.0\build\output\jboss-4.0.3RC2\lib\endorsed\resolver.jar;C:\cvs\JBoss4.0\jboss-4.0\build\output\jboss-4.0.3RC2\lib\endorsed\serializer.jar;C:\cvs\JBoss4.0\jboss-4.0\build\output\jboss-4.0.3RC2\lib\endorsed\xalan.jar;C:\cvs\JBoss4.0\jboss-4.0\build\output\jboss-4.0.3RC2\lib\endorsed\xercesImpl.jar;C:\cvs\JBoss4.0\jboss-4.0\build\output\jboss-4.0.3RC2\lib\endorsed\xml-apis.jar;C:\usr\java\jdk1.5.0_04\jre\lib\rt.jar;C:\usr\java\jdk1.5.0_04\jre\lib\i18n.jar;C:\usr\java\jdk1.5.0_04\jre\lib\sunrsasign.jar;C:\usr\java\jdk1.5.0_04\jre\lib\jsse.jar;C:\usr\java\jdk1.5.0_04\jre\lib\jce.jar;C:\usr\java\jdk1.5.0_04\jre\lib\charsets.jar;C:\usr\java\jdk1.5.0_04\jre\classes
2005-09-06 19:57:52,427 INFO [ScopedXalanUnitTestCase] foundclasses.java.ext.dirs=[]
2005-09-06 19:57:52,427 INFO [ScopedXalanUnitTestCase] version.JAXP=1.1 or higher
2005-09-06 19:57:52,427 INFO [ScopedXalanUnitTestCase] version.DOM.draftlevel=2.0fd
2005-09-06 19:57:52,427 INFO [ScopedXalanUnitTestCase] version.SAX=2.0
2005-09-06 19:57:52,427 INFO [ScopedXalanUnitTestCase] version.ant=not-present
2005-09-06 19:57:52,427 INFO [ScopedXalanUnitTestCase] version.xalan2x=Xalan Java 2.5.2
2005-09-06 19:57:52,427 INFO [ScopedXalanUnitTestCase] version.xerces2=Xerces-J 2.7.1
2005-09-06 19:57:52,427 INFO [ScopedXalanUnitTestCase] *******************************************************
2005-09-06 19:57:52,427 INFO [ScopedXalanUnitTestCase] Default deployment uses xalan version: Xalan Java 2.7.0
2005-09-06 19:57:52,427 INFO [ScopedXalanUnitTestCase] Scoped deployment uses xalan version : Xalan Java 2.5.2
2005-09-06 19:57:52,427 INFO [ScopedXalanUnitTestCase] *******************************************************

Both seem to see the scoped loader, so I'm not sure what is meant by the j2sdk1.4.2 issue.

[dimitris]

Yes, this works because xalan is in lib/endorsed, but if you move it to server/xxx/lib the test will show in the j2sdk1.4 case that the version used by default is 2.4.1 !

[starksm64]

I thought I had moved the xalan.jar from endoresed/lib to server/x/lib in both examples. Where is the "Xalan Java 2.5.2" version info coming from then if the endoresed version is being picked up? I'm retesting the jdk1.4.2 run with this moved for sure now.

[starksm64]

So the test runs fine for me under jdk1.4.2_06 with the xalan.jar moved out of the endorsed lib directory.

12:17:37,286 INFO [Server] Starting JBoss (MX MicroKernel)...
12:17:37,286 INFO [Server] Release ID: JBoss [Zion] 4.0.3RC2 (build: CVSTag=Branch_4_0 date=200509062154)
12:17:37,286 INFO [Server] Home Dir: C:\cvs\JBoss4.0\jboss-4.0\build\output\jboss-4.0.3RC2
12:17:37,286 INFO [Server] Home URL: file:/C:/cvs/JBoss4.0/jboss-4.0/build/output/jboss-4.0.3RC2/
12:17:37,286 INFO [Server] Patch URL: null
12:17:37,286 INFO [Server] Server Name: default
12:17:37,286 INFO [Server] Server Home Dir: C:\cvs\JBoss4.0\jboss-4.0\build\output\jboss-4.0.3RC2\server\default
12:17:37,302 INFO [Server] Server Home URL: file:/C:/cvs/JBoss4.0/jboss-4.0/build/output/jboss-4.0.3RC2/server/default/
12:17:37,302 INFO [Server] Server Temp Dir: C:\cvs\JBoss4.0\jboss-4.0\build\output\jboss-4.0.3RC2\server\default\tmp
12:17:37,302 INFO [Server] Root Deployment Filename: jboss-service.xml
12:17:37,818 INFO [ServerInfo] Java version: 1.4.2_06,Sun Microsystems Inc.
12:17:37,818 INFO [ServerInfo] Java VM: Java HotSpot(TM) Server VM 1.4.2_06-b03 ,Sun Microsystems Inc.

[starksm@banshee9100 testsuite]$ run_tests.sh
ant -Dtest=org.jboss.test.xslt.test.ScopedXalanUnitTestCase -Dnojars=t
Buildfile: build.xml
Overriding previous definition of reference to xdoclet.task.classpath

one-test:
 [mkdir] Created dir: C:\cvs\JBoss4.0\jboss-4.0\testsuite\output\log
 [junit] Running org.jboss.test.xslt.test.ScopedXalanUnitTestCase
 [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.407 sec


2005-09-08 12:53:24,177 INFO [org.jboss.test.xslt.test.ScopedXalanUnitTestCase]
 *******************************************************
2005-09-08 12:53:24,177 INFO [org.jboss.test.xslt.test.ScopedXalanUnitTestCase]
 Default deployment uses xalan version: Xalan Java 2.4.1
2005-09-08 12:53:24,177 INFO [org.jboss.test.xslt.test.ScopedXalanUnitTestCase]
 Scoped deployment uses xalan version : Xalan Java 2.5.2
2005-09-08 12:53:24,177 INFO [org.jboss.test.xslt.test.ScopedXalanUnitTestCase]

Are we doing enough validation in the test? What errors are you seeing under jdk1.4.2?

[dimitris]

Scott, sorry if I don't explain this well. :)

The test *always* succeeds and shows the scoped deployment (the .sar one) gets to use the embedded xalan 2.5.2, whether running with jdk1.4 or jdk5.

The interesting detail is the xalan version that is reported by the default deployment (the -service.xml one), that just uses whatever xalan version is seen by default.

When xalan is in lib/endorsed, using both jdks the xalan version seen is 2.7.0 (or 2.6.0 if you've updated to the rollbacked version).

However, if you move xalan to server/default/lib, running the test under jdk5 will report the correct version (2.7.0 or 2.6.0), *but* running under jdk1.4 will report NOT the version in server/default/lib, but the version included with jdk1.4, which is 2.4.1, as is shown in you latest example! So in this case our xalan lib is practically ignored.

I've updated the JIRA task, if you want to have a look, too:

http://jira.jboss.com/jira/browse/JBAS-2073

[starksm64]

Ok, so your saying its this:

 TransformerFactory tf = TransformerFactory.newInstance();

that is not working based on just the class loader configuration? I don't expect that to as the TransformerFactory is a bundled class and cannot be overriden. The full definition of the jaxp algorigthm for locating the TransformerFactory instance is:

public static TransformerFactory newInstance()
throws TransformerFactoryConfigurationError

Obtain a new instance of a TransformerFactory. This static method creates a new factory instance This method uses the following ordered lookup procedure to determine the TransformerFactory implementation class to load:

* Use the javax.xml.transform.TransformerFactory system property.
* Use the properties file "lib/jaxp.properties" in the JRE directory. This configuration file is in standard java.util.Properties format and contains the fully qualified name of the implementation class with the key being the system property defined above.
* Use the Services API (as detailed in the JAR specification), if available, to determine the classname. The Services API will look for a classname in the file META-INF/services/javax.xml.transform.TransformerFactory in jars available to the runtime.
* Platform default TransformerFactory instance.

Once an application has obtained a reference to a TransformerFactory it can use the factory to configure and obtain parser instances.

The first two approaches are really global vm override mechanisms that cannot be used in general by applications. Only the Services API approach (http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html) ties into the scoped class loading mechanism. This is what the testcase needs to be doing to obtain the transformer. Have you tried that?

Service Provider
Overview
Files in the META-INF/services directory are service provider configuration files. A service is a well-known set of interfaces and (usually abstract) classes. A service provider is a specific implementation of a service. The classes in a provider typically implement the interfaces and subclass the classes defined in the service itself. Service providers may be installed in an implementation of the Java platform in the form of extensions, that is, jar files placed into any of the usual extension directories. Providers may also be made available by adding them to the applet or application class path or by some other platform-specific means.

A service is represented by an abstract class. A provider of a given service contains one or more concrete classes that extend this service class with data and code specific to the provider. This provider class will typically not be the entire provider itself but rather a proxy that contains enough information to decide whether the provider is able to satisfy a particular request together with code that can create the actual provider on demand. The details of provider classes tend to be highly service-specific; no single class or interface could possibly unify them, so no such class has been defined. The only requirement enforced here is that provider classes must have a zero-argument constructor so that they may be instantiated during lookup.

Provider-Configuration File
A service provider identifies itself by placing a provider-configuration file in the resource directory META-INF/services. The file's name should consist of the fully-qualified name of the abstract service class. The file should contain a newline-separated list of unique concrete provider-class names. Space and tab characters, as well as blank lines, are ignored. The comment character is '#' (0x23); on each line all characters following the first comment character are ignored. The file must be encoded in UTF-8.

Example
Suppose we have a service class named java.io.spi.CharCodec. It has two abstract methods:

public abstract CharEncoder getEncoder(String encodingName);
public abstract CharDecoder getDecoder(String encodingName);

Each method returns an appropriate object or null if it cannot translate the given encoding. Typical CharCodec providers will support more than one encoding.

If sun.io.StandardCodec is a provider of the CharCodec service then its jar file would contain the file META-INF/services/java.io.spi.CharCodec. This file would contain the single line:

sun.io.StandardCodec # Standard codecs for the platform

To locate an encoder for a given encoding name, the internal I/O code would do something like this:

CharEncoder getEncoder(String encodingName) {
Iterator ps = Service.providers(CharCodec.class);
while (ps.hasNext()) {
CharCodec cc = (CharCodec)ps.next();
CharEncoder ce = cc.getEncoder(encodingName);
if (ce != null)
return ce;
}
return null;
}


The provider-lookup mechanism always executes in the security context of the caller. Trusted system code should typically invoke the methods in this class from within a privileged security context.

[dimitris]

No, I haven't tried that. I looked around a bit and it seems this is a proprietary feature of sun jdk (sun.misc.Service):

http://bugs.sun.com/bugdatabase/view_bug.do;:YfiG?bug_id=4640520

(BTW: Xalan does include this file in the jar
META-INF/services/javax.xml.transform.TransformerFactory
with content:
org.apache.xalan.processor.TransformerFactoryImpl)

Still, even if that works somehow, wouldn't that mean that user code deployed in jboss, would have to be coded in a special way to look up our server/lib/xalan ?

[starksm64]

The META-INF/services concept and usage are standard along with the JAXP definition of how this should be used. That bug report simply is an RFE saying that the current sun specific mechanism should be promoted to a standard utility.

Nothing should change in the code looking up the factory. What has to change is that the deployment include the correct META-INF/services/* mapping. If the xalan.jar has this, then this should just work, so my question is back to what is not working? As far as I can see from the output the xalan-check-default.sar is seeing the 2.4.1 version:

2005-09-08 12:53:24,115 INFO [org.jboss.test.xslt.test.ScopedXalanUnitTestCase] ***XalanCheckDefault***
2005-09-08 12:53:24,115 INFO [org.jboss.test.xslt.test.ScopedXalanUnitTestCase] version.xerces1=not-present
2005-09-08 12:53:24,115 INFO [org.jboss.test.xslt.test.ScopedXalanUnitTestCase] java.ext.dirs=C:\usr\java\j2sdk1.4.2_06\jre\lib\ext
2005-09-08 12:53:24,115 INFO [org.jboss.test.xslt.test.ScopedXalanUnitTestCase] foundclasses.java.class.path=[]
2005-09-08 12:53:24,115 INFO [org.jboss.test.xslt.test.ScopedXalanUnitTestCase] version.DOM=2.0
2005-09-08 12:53:24,115 INFO [org.jboss.test.xslt.test.ScopedXalanUnitTestCase] java.version=1.4.2_06
2005-09-08 12:53:24,115 INFO [org.jboss.test.xslt.test.ScopedXalanUnitTestCase] version.xalan2_2=Xalan Java 2.4.1
[org.jboss.test.xslt.test.ScopedXalanUnitTestCase] version.JAXP=1.1
[org.jboss.test.xslt.test.ScopedXalanUnitTestCase] version.xalan2x=Xalan Java 2.4.1
2005-09-08 12:53:24,115 INFO [org.jboss.test.xslt.test.ScopedXalanUnitTestCase] version.xerces2=Xerces-J 2.7.1

I'm an idiot, spell it out for me.

[dimitris]

The whole issue I'm pointing out is we would like XalanCheckDefault to see 2.6.0 (or 2.7.0, the library we drop in server/xxx/lib) rather than 2.4.1 (the old xalan library bundled with jdk1.4), and this doesn't work in jdk1.4.

maybe I should just add an assertion for this in the test:

// make sure we override the jdk1.4 default xalan lib
assertTrue("Expected default xalan version != 'Xalan Java 2.4.1'",
!vdefault.equals("Xalan Java 2.4.1"));

[starksm64]

The test needs to use hard assertions for its expectations. I don't want to have to look at the log to know whether the test has passed. I'm not convinced that org.apache.xalan.xslt.EnvironmentCheck is the correct way to be validating the version because this is not used in the jaxp TransformerFactory logic as far as I can see. The problem in general with checking classes unique to a legacy version is that you may very well be able to see the unique classes, but what you really want to validate is that the classes in common with different signatures are as expected.

[dimitris]

I was looking closer at org.apache.xalan.xslt.EnvironmentCheck.checkProcessorVersion()

For the version of interest to us (i.e. 2.2+ --> 2.4.1, 2.5.2, 2.6.0, 2.7.)
the checking code basically does org.apache.xalan.Version.getVersion() :

 try
 {
 // NOTE: This is the new Xalan 2.2+ version class
 final String XALAN2_2_VERSION_CLASS =
 "org.apache.xalan.Version";
 final String XALAN2_2_VERSION_METHOD = "getVersion";
 final Class noArgs[] = new Class[0];

 Class clazz = ObjectFactory.findProviderClass(
 XALAN2_2_VERSION_CLASS, ObjectFactory.findClassLoader(), true);

 Method method = clazz.getMethod(XALAN2_2_VERSION_METHOD, noArgs);
 Object returnValue = method.invoke(null, new Object[0]);

 h.put(VERSION + "xalan2_2", (String)returnValue);
 }
 catch (Exception e2)
 {
 h.put(VERSION + "xalan2_2", CLASS_NOTPRESENT);
 }

Given that the looked up Version class exists in all the 2.2+ xalan versions, is it possible to get back the version that you expect for the scoped deployment (i.e. 2.5.2) if you are seeing the wrong version of the class?

[starksm64]

It looks like it depends on how the ObjectFactory class is loaded. If that is loaded via the thread context class loader or the class loader of the transformer factory implementation that should be a valid check.

[dimitris]

I think it uses the TCL, all right. But I found a killer one:

http://issues.apache.org/bugzilla/show_bug.cgi?id=15140

This bug exists only in 2.5.2, with a test to verify it, so I'll add it to the Scoped test case.

[dimitris]

To check the xalan version I changed the test to load explicitly org.apache.xalan.Version through the thread context classloader, just to be sure.

The 2.5.2 only bug also looks reliable, I've checked this will all jdk combinations / xalan version, and added assertions as well.

Finally, I added an assertion to make sure the default deployment doesn't see xalan 2.4.1 (the jdk1.4 one). This one fails only under jdk1.4, if you move xalan out of lib/endorsed.

[starksm64]

Ok, I get the test finally. The only problem I see is that the tests and assertions about the default xalan version are jdk specific when the xalan.jar is not in the server endorsed/lib. Its just information that cannot really be validated against any meaningful assumptions.

I'm just going to remove the assertion about the 2.4.1/sun jdk1.4.2 test and close the issue as done with the xalan.jar moved out of the endorsed lib into the server/x/lib. Arguably we should just remove the xalan.jar altogether as its bundling is really coming from 3.2.x and the jdk1.3 requirement as jdk1.3 does not have a bundled xslt parser. The jdk1.4.2 xsl is fine for the server needs, and can be overriden either globally by droping a parser into the root lib/endorsed or per app using a scoped deployment.

The change in behavior is that the default xsl parser goes from that bundled with the server to whatever is bundled with the jdk.