[
https://issues.apache.org/jira/browse/CXF-1231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12545151
]
Benson Margulies commented on CXF-1231:
---------------------------------------
I can add a little more color commentary to this.
The Javascript generator code serializes a wrapped operation by using the
element and type it finds hanging off the wrapped part in the wrapped operation.
The DocLitInterceptor, on the other hand, uses the unwrapped parts from the
unwrapped operation.
In this case (name conflict between XmlRootElement and WebParam), the two
disagree. The unwrapped part has a concreteName from the XmlRootElement, while
the complex type has the name from the WebParam.
It would be convenient, needless to say, if they agreed with each other.
> When @WebParam fights with @XmlRootElement, who is supposed to win?
> -------------------------------------------------------------------
>
> Key: CXF-1231
> URL: https://issues.apache.org/jira/browse/CXF-1231
> Project: CXF
> Issue Type: Bug
> Components: JAXB Databinding
> Affects Versions: 2.1
> Reporter: Benson Margulies
> Assignee: Daniel Kulp
>
> In the Javascript project, you will find a test called
> DocLitWrappedClientTest. If you remove the Ignore from a case, it will fail.
> The failure occurs as follows:
> In SimpleDocLitWrapped (the SEI), the method beanFunction is defined to have,
> as its first parameter, an item with an explicit name of 'bean1' in the
> @WebParam.
> However, that parameter is of type TestBean1, which has an @XmlRootElement
> without a name parameter.
> The result of this is that the service model sets up, at runtime, with a
> MessagePartInfo with a concrete name derived from the XmlRootElement.
> If this is correct, please tell me so and close this report. If the @WebParam
> is supposed to win the fight, on the other hand, we've got a bug.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
