You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Benson Margulies (JIRA)" <ji...@apache.org> on 2007/11/23 23:48:43 UTC

[jira] Created: (CXF-1230) DataReader tries to handle 'wrapped' messages and produces misleading validation

DataReader tries to handle 'wrapped' messages and produces misleading validation
--------------------------------------------------------------------------------

                 Key: CXF-1230
                 URL: https://issues.apache.org/jira/browse/CXF-1230
             Project: CXF
          Issue Type: Bug
          Components: JAXB Databinding
    Affects Versions: 2.1
            Reporter: Benson Margulies
            Assignee: Daniel Kulp
            Priority: Minor


Consider a wrapped method that has no explicit @RequestWrapper. In JAXB+JAXWS, the recognition of the XML is handled in the interceptors.

Nonetheless, you can ask the JAXB data binding object for a reader on such a message, and it will give you one. That reader, presented with the wrapper element, will hit a validation error that is rather misleading. The following exception is claiming that the reader will accept either (a) the element for the first of the wrapped parameters, or (b) the entire object for some other message altogether! The first is not altogether nutty, perhaps the reader actually is supposed to handle the individual parameter items. But why is it offering to accept the second?

This level of modularity is, of course, not prime real estate, so I wouldn't expect anyone to drop other tasks and run here.  I'll find some other way to test what I wanted to test.

javax.xml.bind.UnmarshalException: unexpected element (uri:"uri:org.apache.cxf.javascript.fortest", local:"beanFunction"). Expected elements are <{uri:org.apache.cxf.javascript.testns}basicTypeFunctionReturnStringWrapper>,<{uri:org.apache.cxf.javascript.testns}stringWrapper>,<{uri:org.apache.cxf.javascript.testns}testBean1>
	at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.handleEvent(UnmarshallingContext.java:603)




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


[jira] Resolved: (CXF-1230) DataReader tries to handle 'wrapped' messages and produces misleading validation

Posted by "Daniel Kulp (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/CXF-1230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Daniel Kulp resolved CXF-1230.
------------------------------



I believe this is now fixed in 2.1.   In 2.1, if there are no RequestWrapper objects, we actually use ASM to generate one in memory so that all the JAXB annotations can be handled properly.   Thus, at validation time, the appropriate "top level" element is found.


> DataReader tries to handle 'wrapped' messages and produces misleading validation
> --------------------------------------------------------------------------------
>
>                 Key: CXF-1230
>                 URL: https://issues.apache.org/jira/browse/CXF-1230
>             Project: CXF
>          Issue Type: Bug
>          Components: JAXB Databinding
>    Affects Versions: 2.1
>            Reporter: Benson Margulies
>            Assignee: Daniel Kulp
>            Priority: Minor
>             Fix For: 2.1
>
>
> Consider a wrapped method that has no explicit @RequestWrapper. In JAXB+JAXWS, the recognition of the XML is handled in the interceptors.
> Nonetheless, you can ask the JAXB data binding object for a reader on such a message, and it will give you one. That reader, presented with the wrapper element, will hit a validation error that is rather misleading. The following exception is claiming that the reader will accept either (a) the element for the first of the wrapped parameters, or (b) the entire object for some other message altogether! The first is not altogether nutty, perhaps the reader actually is supposed to handle the individual parameter items. But why is it offering to accept the second?
> This level of modularity is, of course, not prime real estate, so I wouldn't expect anyone to drop other tasks and run here.  I'll find some other way to test what I wanted to test.
> javax.xml.bind.UnmarshalException: unexpected element (uri:"uri:org.apache.cxf.javascript.fortest", local:"beanFunction"). Expected elements are <{uri:org.apache.cxf.javascript.testns}basicTypeFunctionReturnStringWrapper>,<{uri:org.apache.cxf.javascript.testns}stringWrapper>,<{uri:org.apache.cxf.javascript.testns}testBean1>
> 	at com.sun.xml.bind.v2.runtime.unmarshaller.UnmarshallingContext.handleEvent(UnmarshallingContext.java:603)

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