4:47 p.m.
Replying inline to be more clear.
On Feb 20, 2013, at 8:24 AM, Jan J. Roman <mail(a)jjroman.net> 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).
That's not quite right. The com.sun.* class is a JDK class it's not in the xalan
library we ship. If something ever picks
org.apache.xalan.xsltc.trax.TransformerFactoryImpl, it's going to break when a
deployment is involved due to the class loading issues I mentioned in the other email.
I think what you are talking about below is the interpreted version of the transformer,
which is NOT what the JDK uses:
org.apache.xalan.processor.TransformerFactoryImpl
This instance incorectly performs transormation of wsdl inserting
doubled namespace definitions.
That could very well be a bug in the tranelet (compiled ) transformer, however, it could
also be a bug in the xslt, which doesn't happen in the interpreted version. The JDK is
based on the same (but slightly older code), so I would expect that this behavior would
happen on the JDK as well. I think the issue needs to be looked into as to what is causing
this bug. Perhaps a patch is already available.
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/j...
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.
If so that's a pretty big problem because that means that our productization process
lost an upstream patch!
When I revert this change locally - correct class is picked and double namespaces do not
occur.
So the reason I mention that we should look into whats actually causing the bug, is that
interpreted translates are a lot slower than compiled translates. So simply switching to
interpreted isn't a friendly thing to do, and really should only be done if we are
sure its the only realistic option.
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.
It looks like everything is in the github history:
https://github.com/jboss/xalan-j/blob/jboss_2_7_1/maven/pom-xalan.xml
--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat