[
https://issues.apache.org/jira/browse/WSCOMMONS-66?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andreas Veithen updated WSCOMMONS-66:
-------------------------------------
Component/s: AXIOM
> OMSerializerUtil is not calling XMLStreamWriter in the correct order
> --------------------------------------------------------------------
>
> Key: WSCOMMONS-66
> URL: https://issues.apache.org/jira/browse/WSCOMMONS-66
> Project: WS-Commons
> Issue Type: Bug
> Components: AXIOM
> Reporter: Rich Scheuerle
> Assignee: Rich Scheuerle
> Priority: Critical
> Attachments: finalpatch0725.txt
>
>
> OMSerializerUtil is not invoking the XMLStreamWriter in the correct order.
> This causes problems when a different StAX implementation (non-Woodstox) is
> used.
> The suggestion is to change the algorithm to use the same algorithm as
> WSCOMMONS-64. (Actually the best approach is to try and fold the code
> together).
> I think this would also fix several of the other AXION serializer issues.
> Here is the WSCOMMONS-64 algorithm (reccently introduced):
> // The algorithm is:
> // ... generate setPrefix/setDefaultNamespace for each namespace
> declaration if the prefix is unassociated.
> // ... generate setPrefix/setDefaultNamespace if the prefix of the
> element is unassociated
> // ... generate setPrefix/setDefaultNamespace for each unassociated
> prefix of the attributes.
> //
> // ... generate writeStartElement
> //
> // ... generate writeNamespace/writerDefaultNamespace for each
> namespace declaration on the element
> // ... generate writeNamespace/writeDefaultNamespace for any new
> "autogen" namespace/prefixes
> // ... generate writeAttribute for each attribute
>
> Here is the guidance from the JSR173 StAX specification (note that prefixes
> are first "set", then then writeStartElement, then the namespace
> declarations are generated). This is not being followed in OMSerializerUtil
> ----------------
> writer.setPrefix("c","http://c";);
> writer.setDefaultNamespace("http://c";);
> writer.writeStartElement("http://c","a";);
> writer.writeAttribute("b","blah");
> writer.writeNamespace("c","http://c";);
> writer.writeDefaultNamespace("http://c";);
> writer.setPrefix("d","http://c";);
> writer.writeEmptyElement("http://c","d";);
> writer.writeAttribute("http://c","chris","fry";);
> writer.writeNamespace("d","http://c";);
> writer.writeCharacters("foo bar foo");
> writer.writeEndElement();
> writer.flush();
> This will result in the following XML (new lines are non-normative)
> <?xml version='1.0' encoding='utf-8'?>
> <a b="blah" xmlns:c="http://c"; xmlns="http://c";>
> <d:d d:chris="fry" xmlns:d="http://c"/>foo bar foo</a>
> ---------------------
> Here is the specific exception that I get when I plug in a different StAX
> implementation:
> java.lang.IllegalStateException: writeNamespace() can only be called
> following writeStartElement() or writeEmptyElement().
> at .....
> at
> org.apache.axiom.om.impl.MTOMXMLStreamWriter.writeNamespace(MTOMXMLStreamWriter.java:150)
> at
> org.apache.axiom.om.impl.util.OMSerializerUtil.serializeNamespace(OMSerializerUtil.java:116)
> at
> org.apache.axiom.om.impl.util.OMSerializerUtil.serializeNamespaces(OMSerializerUtil.java:264)
> at
> org.apache.axiom.om.impl.util.OMSerializerUtil.serializeStartpart(OMSerializerUtil.java)
> at
> org.apache.axiom.om.impl.llom.OMElementImpl.internalSerialize(OMElementImpl.java:767)
> at
> org.apache.axiom.om.impl.llom.OMElementImpl.internalSerialize(OMElementImpl.java:756)
> at
> org.apache.axiom.om.impl.llom.OMNodeImpl.serialize(OMNodeImpl.java:310)
> at
> org.apache.axiom.om.impl.llom.OMNodeImpl.serialize(OMNodeImpl.java:348)
> at
> org.apache.axiom.om.impl.llom.OMElementImpl.toString(OMElementImpl.java:899)
> at
> org.apache.axiom.om.impl.serializer.PreserveEnvelopeTest.testOMNS(PreserveEnvelopeTest.java:80)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:615)
> at junit.framework.TestCase.runTest(TestCase.java:154)
> at junit.framework.TestCase.runBare(TestCase.java:127)
> at junit.framework.TestResult$1.protect(TestResult.java:106)
> at junit.framework.TestResult.runProtected(TestResult.java:124)
> at junit.framework.TestResult.run(TestResult.java:109)
> at junit.framework.TestCase.run(TestCase.java:118)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:478)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:344)
> at
> org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
> --------------------------
> I have assigned this issue to myself and will submit a patch for the fix.
> As with WSCOMMONS-64, I would like a peer review of the idea and change.
> (Note: I worked extensively on the SAX model in Axis and within other
> webservice projects...so I am familiar with this problem domain).
> Thanks for your help.
> scheu
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
