You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commons-dev@ws.apache.org by "Davanum Srinivas (JIRA)" <ji...@apache.org> on 2006/07/25 15:26:14 UTC
[jira] Commented: (WSCOMMONS-66) OMSerializerUtil is not calling
XMLStreamWriter in the correct order
[ http://issues.apache.org/jira/browse/WSCOMMONS-66?page=comments#action_12423334 ]
Davanum Srinivas commented on WSCOMMONS-66:
-------------------------------------------
go for it!
-- dims
> 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: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org