[jira] Created: (CXF-2510) XMLBEANS_NAMESPACE_HACK alternative is missing in case of XmlBeans data binding

XMLBEANS_NAMESPACE_HACK alternative is missing in case of XmlBeans data binding
-------------------------------------------------------------------------------

                 Key: CXF-2510
                 URL: https://issues.apache.org/jira/browse/CXF-2510
             Project: CXF
          Issue Type: Bug
          Components: OtherDatabindings
            Reporter: Michael Klimiuk
            Priority: Critical


MAIN DESCRIPTION

Is there a chance to port the XMLBEANS_NAMESPACE_HACK feature from XFire to CXF?

Here is a reference: http://xfire.codehaus.org/XMLBeans+Integration



PROBLEM

CXF always use XMLBeans XMLStreamReader to write to the outgoing xml stream.

There is a number of issues related to namespaces when this reader is used, e.g.:

1. It either fails to read info or fails to write info in some cases.

2. Namespaces are duplicated for each element even with
   the fix http://issues.apache.org/jira/browse/CXF-2468

If there was an opportunity to switch CXF to use XMLBeans DOM as a source object
instead of XMLStreamReader then I suppose these issues would be resolved.



BACKGROUND - SOME XFIRE SOURCES

xfire-1.2.4\xfire-xmlbeans\src\main\org\codehaus\xfire\xmlbeans\XmlBeansType.java

Here is an excerpt from the XmlBeansType.writeObject(..) method:

            if (Boolean.valueOf((String) context.getContextualProperty(XMLBEANS_NAMESPACE_HACK)).booleanValue())
            {
                Object o = obj.newDomNode();
                if (o instanceof Document)
                {
                    org.w3c.dom.Element e = ((Document) o).getDocumentElement();
                    STAXUtils.writeElement(e, xsw, false);
                }
                else if (o instanceof DocumentFragment)
                {
                    DocumentFragment frag = (DocumentFragment) o;
                   
                    NodeList nodes = frag.getChildNodes();
                    Node node = nodes.item(0);
                    nodes = node.getChildNodes();
                    for (int i = 0; i < nodes.getLength(); i++)
                    {
                        STAXUtils.writeNode(nodes.item(i), xsw, false);
                    }
                }
                else
                {
                    throw new XFireRuntimeException("Invalid document type returned: " + o);
                }
            }
            else
            {
                XmlCursor cursor = obj.newCursor();
               
                STAXUtils.copy(cursor.newXMLStreamReader(),
                                ((ElementWriter) writer).getXMLStreamWriter());
            }

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

     [ https://issues.apache.org/jira/browse/CXF-2510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Daniel Kulp reassigned CXF-2510:
--------------------------------

    Assignee: Daniel Kulp

> XMLBEANS_NAMESPACE_HACK alternative is missing in case of XmlBeans data binding
> -------------------------------------------------------------------------------
>
>                 Key: CXF-2510
>                 URL: https://issues.apache.org/jira/browse/CXF-2510
>             Project: CXF
>          Issue Type: Bug
>          Components: OtherDatabindings
>            Reporter: Michael Klimiuk
>            Assignee: Daniel Kulp
>            Priority: Critical
>
> MAIN DESCRIPTION
> Is there a chance to port the XMLBEANS_NAMESPACE_HACK feature from XFire to CXF?
> Here is a reference: http://xfire.codehaus.org/XMLBeans+Integration
> PROBLEM
> CXF always use XMLBeans XMLStreamReader to write to the outgoing xml stream.
> There is a number of issues related to namespaces when this reader is used, e.g.:
> 1. It either fails to read info or fails to write info in some cases.
> 2. Namespaces are duplicated for each element even with
>    the fix http://issues.apache.org/jira/browse/CXF-2468
> If there was an opportunity to switch CXF to use XMLBeans DOM as a source object
> instead of XMLStreamReader then I suppose these issues would be resolved.
> BACKGROUND - SOME XFIRE SOURCES
> xfire-1.2.4\xfire-xmlbeans\src\main\org\codehaus\xfire\xmlbeans\XmlBeansType.java
> Here is an excerpt from the XmlBeansType.writeObject(..) method:
>             if (Boolean.valueOf((String) context.getContextualProperty(XMLBEANS_NAMESPACE_HACK)).booleanValue())
>             {
>                 Object o = obj.newDomNode();
>                 if (o instanceof Document)
>                 {
>                     org.w3c.dom.Element e = ((Document) o).getDocumentElement();
>                     STAXUtils.writeElement(e, xsw, false);
>                 }
>                 else if (o instanceof DocumentFragment)
>                 {
>                     DocumentFragment frag = (DocumentFragment) o;
>                    
>                     NodeList nodes = frag.getChildNodes();
>                     Node node = nodes.item(0);
>                     nodes = node.getChildNodes();
>                     for (int i = 0; i < nodes.getLength(); i++)
>                     {
>                         STAXUtils.writeNode(nodes.item(i), xsw, false);
>                     }
>                 }
>                 else
>                 {
>                     throw new XFireRuntimeException("Invalid document type returned: " + o);
>                 }
>             }
>             else
>             {
>                 XmlCursor cursor = obj.newCursor();
>                
>                 STAXUtils.copy(cursor.newXMLStreamReader(),
>                                 ((ElementWriter) writer).getXMLStreamWriter());
>             }

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

     [ https://issues.apache.org/jira/browse/CXF-2510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Daniel Kulp resolved CXF-2510.
------------------------------

       Resolution: Fixed
    Fix Version/s: 2.2.5

> XMLBEANS_NAMESPACE_HACK alternative is missing in case of XmlBeans data binding
> -------------------------------------------------------------------------------
>
>                 Key: CXF-2510
>                 URL: https://issues.apache.org/jira/browse/CXF-2510
>             Project: CXF
>          Issue Type: Bug
>          Components: OtherDatabindings
>            Reporter: Michael Klimiuk
>            Assignee: Daniel Kulp
>            Priority: Critical
>             Fix For: 2.2.5
>
>
> MAIN DESCRIPTION
> Is there a chance to port the XMLBEANS_NAMESPACE_HACK feature from XFire to CXF?
> Here is a reference: http://xfire.codehaus.org/XMLBeans+Integration
> PROBLEM
> CXF always use XMLBeans XMLStreamReader to write to the outgoing xml stream.
> There is a number of issues related to namespaces when this reader is used, e.g.:
> 1. It either fails to read info or fails to write info in some cases.
> 2. Namespaces are duplicated for each element even with
>    the fix http://issues.apache.org/jira/browse/CXF-2468
> If there was an opportunity to switch CXF to use XMLBeans DOM as a source object
> instead of XMLStreamReader then I suppose these issues would be resolved.
> BACKGROUND - SOME XFIRE SOURCES
> xfire-1.2.4\xfire-xmlbeans\src\main\org\codehaus\xfire\xmlbeans\XmlBeansType.java
> Here is an excerpt from the XmlBeansType.writeObject(..) method:
>             if (Boolean.valueOf((String) context.getContextualProperty(XMLBEANS_NAMESPACE_HACK)).booleanValue())
>             {
>                 Object o = obj.newDomNode();
>                 if (o instanceof Document)
>                 {
>                     org.w3c.dom.Element e = ((Document) o).getDocumentElement();
>                     STAXUtils.writeElement(e, xsw, false);
>                 }
>                 else if (o instanceof DocumentFragment)
>                 {
>                     DocumentFragment frag = (DocumentFragment) o;
>                    
>                     NodeList nodes = frag.getChildNodes();
>                     Node node = nodes.item(0);
>                     nodes = node.getChildNodes();
>                     for (int i = 0; i < nodes.getLength(); i++)
>                     {
>                         STAXUtils.writeNode(nodes.item(i), xsw, false);
>                     }
>                 }
>                 else
>                 {
>                     throw new XFireRuntimeException("Invalid document type returned: " + o);
>                 }
>             }
>             else
>             {
>                 XmlCursor cursor = obj.newCursor();
>                
>                 STAXUtils.copy(cursor.newXMLStreamReader(),
>                                 ((ElementWriter) writer).getXMLStreamWriter());
>             }

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

     [ https://issues.apache.org/jira/browse/CXF-2510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Klimiuk reopened CXF-2510:
----------------------------------


Hi Daniel,

It seems one conditional statement is missed in the fix.

The logic after this condition:

    if (message != null
        && MessageUtils.getContextualBoolean(message,
            XmlBeansDataBinding.XMLBEANS_NAMESPACE_HACK,
                false)) {

should be in ELSE block:

137    } else {
               XMLStreamReader reader;
               if (obj instanceof XmlObjectBase) {
                   XmlObjectBase source = (XmlObjectBase)obj;
                   reader = source.newCursorForce().newXMLStreamReader(options);
               ...
               } else {
                   StaxUtils.copy(reader, output, true);
               }
169    }

I.e. this ELSE block statement is missed.

Please check.

> XMLBEANS_NAMESPACE_HACK alternative is missing in case of XmlBeans data binding
> -------------------------------------------------------------------------------
>
>                 Key: CXF-2510
>                 URL: https://issues.apache.org/jira/browse/CXF-2510
>             Project: CXF
>          Issue Type: Bug
>          Components: OtherDatabindings
>            Reporter: Michael Klimiuk
>            Assignee: Daniel Kulp
>            Priority: Critical
>             Fix For: 2.2.5
>
>
> MAIN DESCRIPTION
> Is there a chance to port the XMLBEANS_NAMESPACE_HACK feature from XFire to CXF?
> Here is a reference: http://xfire.codehaus.org/XMLBeans+Integration
> PROBLEM
> CXF always use XMLBeans XMLStreamReader to write to the outgoing xml stream.
> There is a number of issues related to namespaces when this reader is used, e.g.:
> 1. It either fails to read info or fails to write info in some cases.
> 2. Namespaces are duplicated for each element even with
>    the fix http://issues.apache.org/jira/browse/CXF-2468
> If there was an opportunity to switch CXF to use XMLBeans DOM as a source object
> instead of XMLStreamReader then I suppose these issues would be resolved.
> BACKGROUND - SOME XFIRE SOURCES
> xfire-1.2.4\xfire-xmlbeans\src\main\org\codehaus\xfire\xmlbeans\XmlBeansType.java
> Here is an excerpt from the XmlBeansType.writeObject(..) method:
>             if (Boolean.valueOf((String) context.getContextualProperty(XMLBEANS_NAMESPACE_HACK)).booleanValue())
>             {
>                 Object o = obj.newDomNode();
>                 if (o instanceof Document)
>                 {
>                     org.w3c.dom.Element e = ((Document) o).getDocumentElement();
>                     STAXUtils.writeElement(e, xsw, false);
>                 }
>                 else if (o instanceof DocumentFragment)
>                 {
>                     DocumentFragment frag = (DocumentFragment) o;
>                    
>                     NodeList nodes = frag.getChildNodes();
>                     Node node = nodes.item(0);
>                     nodes = node.getChildNodes();
>                     for (int i = 0; i < nodes.getLength(); i++)
>                     {
>                         STAXUtils.writeNode(nodes.item(i), xsw, false);
>                     }
>                 }
>                 else
>                 {
>                     throw new XFireRuntimeException("Invalid document type returned: " + o);
>                 }
>             }
>             else
>             {
>                 XmlCursor cursor = obj.newCursor();
>                
>                 STAXUtils.copy(cursor.newXMLStreamReader(),
>                                 ((ElementWriter) writer).getXMLStreamWriter());
>             }

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

     [ https://issues.apache.org/jira/browse/CXF-2510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Daniel Kulp resolved CXF-2510.
------------------------------

    Resolution: Fixed

Added a missing return at the end of the block for the hack.

> XMLBEANS_NAMESPACE_HACK alternative is missing in case of XmlBeans data binding
> -------------------------------------------------------------------------------
>
>                 Key: CXF-2510
>                 URL: https://issues.apache.org/jira/browse/CXF-2510
>             Project: CXF
>          Issue Type: Bug
>          Components: OtherDatabindings
>            Reporter: Michael Klimiuk
>            Assignee: Daniel Kulp
>            Priority: Critical
>             Fix For: 2.2.5
>
>
> MAIN DESCRIPTION
> Is there a chance to port the XMLBEANS_NAMESPACE_HACK feature from XFire to CXF?
> Here is a reference: http://xfire.codehaus.org/XMLBeans+Integration
> PROBLEM
> CXF always use XMLBeans XMLStreamReader to write to the outgoing xml stream.
> There is a number of issues related to namespaces when this reader is used, e.g.:
> 1. It either fails to read info or fails to write info in some cases.
> 2. Namespaces are duplicated for each element even with
>    the fix http://issues.apache.org/jira/browse/CXF-2468
> If there was an opportunity to switch CXF to use XMLBeans DOM as a source object
> instead of XMLStreamReader then I suppose these issues would be resolved.
> BACKGROUND - SOME XFIRE SOURCES
> xfire-1.2.4\xfire-xmlbeans\src\main\org\codehaus\xfire\xmlbeans\XmlBeansType.java
> Here is an excerpt from the XmlBeansType.writeObject(..) method:
>             if (Boolean.valueOf((String) context.getContextualProperty(XMLBEANS_NAMESPACE_HACK)).booleanValue())
>             {
>                 Object o = obj.newDomNode();
>                 if (o instanceof Document)
>                 {
>                     org.w3c.dom.Element e = ((Document) o).getDocumentElement();
>                     STAXUtils.writeElement(e, xsw, false);
>                 }
>                 else if (o instanceof DocumentFragment)
>                 {
>                     DocumentFragment frag = (DocumentFragment) o;
>                    
>                     NodeList nodes = frag.getChildNodes();
>                     Node node = nodes.item(0);
>                     nodes = node.getChildNodes();
>                     for (int i = 0; i < nodes.getLength(); i++)
>                     {
>                         STAXUtils.writeNode(nodes.item(i), xsw, false);
>                     }
>                 }
>                 else
>                 {
>                     throw new XFireRuntimeException("Invalid document type returned: " + o);
>                 }
>             }
>             else
>             {
>                 XmlCursor cursor = obj.newCursor();
>                
>                 STAXUtils.copy(cursor.newXMLStreamReader(),
>                                 ((ElementWriter) writer).getXMLStreamWriter());
>             }

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

     [ https://issues.apache.org/jira/browse/CXF-2510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Daniel Kulp updated CXF-2510:
-----------------------------

    Fix Version/s: 2.1.8

> XMLBEANS_NAMESPACE_HACK alternative is missing in case of XmlBeans data binding
> -------------------------------------------------------------------------------
>
>                 Key: CXF-2510
>                 URL: https://issues.apache.org/jira/browse/CXF-2510
>             Project: CXF
>          Issue Type: Bug
>          Components: OtherDatabindings
>            Reporter: Michael Klimiuk
>            Assignee: Daniel Kulp
>            Priority: Critical
>             Fix For: 2.1.8, 2.2.5
>
>
> MAIN DESCRIPTION
> Is there a chance to port the XMLBEANS_NAMESPACE_HACK feature from XFire to CXF?
> Here is a reference: http://xfire.codehaus.org/XMLBeans+Integration
> PROBLEM
> CXF always use XMLBeans XMLStreamReader to write to the outgoing xml stream.
> There is a number of issues related to namespaces when this reader is used, e.g.:
> 1. It either fails to read info or fails to write info in some cases.
> 2. Namespaces are duplicated for each element even with
>    the fix http://issues.apache.org/jira/browse/CXF-2468
> If there was an opportunity to switch CXF to use XMLBeans DOM as a source object
> instead of XMLStreamReader then I suppose these issues would be resolved.
> BACKGROUND - SOME XFIRE SOURCES
> xfire-1.2.4\xfire-xmlbeans\src\main\org\codehaus\xfire\xmlbeans\XmlBeansType.java
> Here is an excerpt from the XmlBeansType.writeObject(..) method:
>             if (Boolean.valueOf((String) context.getContextualProperty(XMLBEANS_NAMESPACE_HACK)).booleanValue())
>             {
>                 Object o = obj.newDomNode();
>                 if (o instanceof Document)
>                 {
>                     org.w3c.dom.Element e = ((Document) o).getDocumentElement();
>                     STAXUtils.writeElement(e, xsw, false);
>                 }
>                 else if (o instanceof DocumentFragment)
>                 {
>                     DocumentFragment frag = (DocumentFragment) o;
>                    
>                     NodeList nodes = frag.getChildNodes();
>                     Node node = nodes.item(0);
>                     nodes = node.getChildNodes();
>                     for (int i = 0; i < nodes.getLength(); i++)
>                     {
>                         STAXUtils.writeNode(nodes.item(i), xsw, false);
>                     }
>                 }
>                 else
>                 {
>                     throw new XFireRuntimeException("Invalid document type returned: " + o);
>                 }
>             }
>             else
>             {
>                 XmlCursor cursor = obj.newCursor();
>                
>                 STAXUtils.copy(cursor.newXMLStreamReader(),
>                                 ((ElementWriter) writer).getXMLStreamWriter());
>             }

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.