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 "Rich Scheuerle (JIRA)" <ji...@apache.org> on 2006/07/23 00:11:13 UTC
[jira] Created: (WSCOMMONS-66) OMSerializerUtil is not calling
XMLStreamWriter in the correct order
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
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
[jira] Updated: (WSCOMMONS-66) OMSerializerUtil is not calling
XMLStreamWriter in the correct order
Posted by "Andreas Veithen (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (WSCOMMONS-66) OMSerializerUtil is not calling
XMLStreamWriter in the correct order
Posted by "Rich Scheuerle (JIRA)" <ji...@apache.org>.
[ 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: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org
[jira] Resolved: (WSCOMMONS-66) OMSerializerUtil is not calling
XMLStreamWriter in the correct order
Posted by "Rich Scheuerle (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/WSCOMMONS-66?page=all ]
Rich Scheuerle resolved WSCOMMONS-66.
-------------------------------------
Resolution: Fixed
Per dims request, I am submitting this change.
I did not see any regression differences in Axiom or Axis2.
Eran Chinthaka removed my last change (WSCOMMONS-64).
Please review this change and let me know if any modifications are needed.
Thanks,
scheu
> 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
[jira] Commented: (WSCOMMONS-66) OMSerializerUtil is not calling
XMLStreamWriter in the correct order
Posted by "Davanum Srinivas (JIRA)" <ji...@apache.org>.
[ 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