[jboss-as7-dev] Xalan custom jbossorg release

[Jason Greene]

On Feb 20, 2013, at 8:40 AM, "David M. Lloyd" <david.lloyd at redhat.com> wrote:

> On 02/20/2013 08:24 AM, Jan J. Roman wrote:
>> Hello everyone,
>> I can not get heard on irc ;-) and forum discussion in development area
>> seems to be a bit dead.
>> I would like to start contributing and I have been trying to resolve
>> issue reported here: https://issues.jboss.org/browse/AS7-6390
>> 
>> I came to the point where I figured out that the issue is caused by
>> incorrectly picked TransformerFactory class (it is created as an
>> instance of org.apache.xalan.xsltc.trax.TransformerFactoryImpl instead
>> of com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl).
>> This instance incorectly performs transormation of wsdl inserting
>> doubled namespace definitions.
>> 
>> As it was reported by user this is not happening in Jboss EAP 6.0
>> 
>> I did some investigation and I found that it is caused by change in the
>> file:
>> https://github.com/jboss/xalan-j/blob/jboss_2_7_1/src/META-INF/services/javax.xml.transform.TransformerFactory
>> Change labeled: "Enable xslt" commit:
>> 928a986054f4c67fcd0d62fabec908aa77fdd864
>> 
>> This file exist in xalan-2.7.1-jbossorg-1.jar and
>> xalan-2.7.1-redhat-1.jar but in redhat release it is unchanged.
>> 
>> When I revert this change locally - correct class is picked and double
>> namespaces do not occur.
>> 
>> Another consternation about this third party release is that in nexus
>> repository there is released JAR named: xalan-2.7.1-jbossorg-2 while
>> there is no such version on github. It should not be an issue as by
>> default current builds of AS 6,7 and 8 ;-) are picking
>> xalan-2.7.1-jbossorg-1 but it would be nice to have it sorted.
>> OTOH replacing xalan-2.7.1-jbossorg-1 with xalan-2.7.1-jbossorg-2 does
>> not solve the problem mentioned above.
>> 
>> I am interested to hear your views on the matter.
> 
> I added a comment to the issue.  Hopefully Paul can comment on what 
> motivated the change and his thoughts on its effects.

It's actually my change, which was just a separate patch file before he imported it into a git repo.

The JDK uses compiled translets, since they are significantly faster. Unfortunately the class loading semantics of these compiled translates are wrong and assume a flat class path (the user's classes and the xalan impl classes are on the same class loader). So we had to patch xalan (and fork it since the project is inactive)

So while the JDK used compiled translates, the xalan code has always defaulted to interpreted. This patch just matches the same settings of the JDK.


--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat