[ http://issues.apache.org/jira/browse/WSCOMMONS-66?page=all ]
Rich Scheuerle updated WSCOMMONS-66:
------------------------------------
Attachment: finalpatch0725.txt
I am contributing this patch and welcome the user community to peer review the
changes.
If there is no feedback, I will commit the change.
Thanks,
scheu
Summary of changes:
1) Changed OMSerializerUtil to match the algorithm in StreamingOMSerializer.
The key
point is that both algorithms should follow the same sequence of StAX writes.
I added some code sharing between the two classes.
2) In the process of doing (1), I discovered that the woodstox XMLStreamWriter
and
the other StAX implementations differ on the scoping of setPrefix.
To accomodate both interpretations, I added
OMSerializerUtil.isSetPrefixBeforeStartElement(writer) to
query which interpretation should be used while serializing.
a) This fixed the Axis2 ADBXMLStreamWriterTest (AXIS2-927)
3) Made some minor changes to the algorithm per testing.
4) I made a small change to OMTextImpl to call setPrefix before
writeStartElement.
5) I found similar StAX writer sequencing problems in the SOAP11 implementation
classes.
The code is changed to use OMSerializerUtil.serializeStartpart. This also
supports code reuse.
a) The invalid code used OMSerializerUtil.serializeNamespaces and
serializeAttributes. These
should not be used outside of serializeStartpart, or you can get StAX
errors. To prevent
future problems, I changed both methods to deprecated and added a note to
use serializeStartpart
6) WSCOMMONS-62 is a related bug. I verified that this is fixed by adding a
test using David's contribution.
> OMSerializerUtil is not calling XMLStreamWriter in the correct order
> --------------------------------------------------------------------
>
> Key: WSCOMMONS-66
> URL: http://issues.apache.org/jira/browse/WSCOMMONS-66
> Project: WS-Commons
> Issue Type: Bug
> Reporter: Rich Scheuerle
> Assigned To: 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.
-
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]
