[
http://issues.apache.org/jira/browse/XALANJ-2273?page=comments#action_12367525
]
Henry Zongaro commented on XALANJ-2273:
---------------------------------------
I took a look at the issue that was originally opened against JAXB, and notice
that a JAXB developer had this to say:
In debugging the sample app. using xalan-j_2_7_0 and the
current JAXB I found that if DocumentBuilderFactory.setNamespaceAware is
set to false (setNamespaceAware(false)) then
TransformerIdentityImpl.startElement:1072
calls JAXB's ContentHandlerAdaptor.startElement(String namespaceURI,
String localName, String qName, Attributes atts) passing arg values
of namespaceURI="", localName="test" qName="n:test" this causes
JAXB to generation output,
<test xmlns:ns2="http://my.namespace.com/a"; xmlns=""
xmlns:n="http://my.namespace.com/n";>data</test>
It's the value of namespaceURI that is causing this.
If setNamespaceAware is set to true (setNamespaceAware(true)) then
the values passes to ContentHandlerAdaptor.startElement are
namespaceURI="http://my.namespace.com/n";, localName="test"
qName="n:test" this causes JAXB to generation output,
<n:test xmlns:n="http://my.namespace.com/n";>data</n:test>
I ran the app in both scenarios using jwsdp_1_5 libraries
and got the same result as setNamespaceAware(true).
So xalan is driving the behavior but is this a bug or
a version feature?
That doesn't sound like the JAXB developer definitively said this was a Xalan-J
bug, unless there's some other discussion that I don't know about.
It looks like there's a difference in behaviour between identity transform of
the Xalan-J Interpretive processor and that of XSLTC. Sun's Java 5.0 is
packaged with a version of XSLTC only, so build1.xml is using that processor.
When you add xalan.jar to the classpath in build2.xml, you end up using the
interpretive processor, because xalan.jar contains a
META-INF/services/javax.xml.transform.TransformerFactory file that specifies
the interpretive processor is to be used as the default. You can see the
difference in output by including xalan.jar and serializer.jar on your class
path, and putting a META-INF/services/javax.xml.transform.TransformerFactory
somewhere ahead of it on your classpath. The services file should contain only
the following line to use XSLTC
org.apache.xalan.xsltc.trax.TransformerFactoryImpl
or only the following line to use Xalan-J Interpretive
org.apache.xalan.processor.TransformerFactoryImpl
Or you can select which processor to use on the java invocation command by
setting the javax.xml.transform.Transformer system property with one of those
two values.
In any event, JAXP requires any DOM tree that is passed to a transformation to
built with namespace-awareness set to true; results might be incorrect or
otherwise unexpected if the tree is built with namespace-awareness set to
false. So the fact that there might be a difference in behaviour between the
two processors when given input that was not built with a namespace aware
processor might not be significant. It sounds to me like this is not a bug in
Xalan-J, but I'd have to investigate further to be certain.
> Namespace problem when serializing from JAXB 2.0
> ------------------------------------------------
>
> Key: XALANJ-2273
> URL: http://issues.apache.org/jira/browse/XALANJ-2273
> Project: XalanJ2
> Type: Bug
> Components: Xalan, Serialization
> Versions: Latest Development Code, 2.7
> Environment: Windows XP Pro
> java version "1.5.0_06"
> JAXB 2.0 EA3
> Xerces 2.7.1
> Xalan 2.7.0 and trunk
> Reporter: Golgoth 14
> Priority: Minor
> Attachments: jaxb-test.zip
>
> The marshalling of a JAXB object created by the parsing of XML data with the
> Xerces parser
> gives two differents results if the classpath contains only xerces.jar or if
> it contains xerces.jar, xalan.jar and serializer.jar.
> 1) Classpath with xerces only :
> [java] <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
> [java] <dataDetail xmlns="http://my.namespace.com/a";
> name="datadetail-001">
> [java] <data id="data-001">
> [java] <n:test xmlns:n="http://my.namespace.com/n";>data</n:test>
> [java] </data>
> [java] <data id="data-002">
> [java] <n:test xmlns:n="http://my.namespace.com/n";>data</n:test>
> [java] </data>
> [java] </dataDetail>
> 2) Classpath with xerces, xalan and serializer :
> [java] <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
> [java] <dataDetail xmlns="http://my.namespace.com/a";
> name="datadetail-001">
> [java] <data id="data-001">
> [java] <n:test xmlns:n="http://my.namespace.com/n";>data</n:test>
> [java] </data>
> [java] <data id="data-002">
> [java] <test xmlns:ns2="http://my.namespace.com/a"; xmlns=""
> xmlns:n="http://my.namespace.com/n";>data</test>
> [java] </data>
> [java] </dataDetail>
> I've make test with the released and with the trunk versions of Xalan.
> First, I had posted this bug on the JAXB issue tracker but the JAXB team
> investigations indicated that the problem came from Xalan.
> I've a full test case that you could run with ANT. I will try to attach it.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
