You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Daniel Kulp (JIRA)" <ji...@apache.org> on 2008/02/21 22:37:19 UTC

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

     [ 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.