[
https://issues.apache.org/jira/browse/CXF-5706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13979782#comment-13979782
]
Sergey Beryozkin commented on CXF-5706:
---------------------------------------
You can return an error representation by throwing the exception, so it is not
the only way to have Response generated. There are many combinations possible
with the way response statuses are represented so we can not generalize it
around Response. It will be possible though to nominate method names that will
have Response generated if preferred. Using -tMap might also provide a
workaround
> wadl2java: Return types aren't generated properly on server interfaces for
> methods with more than 1 response element.
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: CXF-5706
> URL: https://issues.apache.org/jira/browse/CXF-5706
> Project: CXF
> Issue Type: Bug
> Components: Tooling
> Affects Versions: 3.0.0-milestone2
> Environment: Java version "1.6.0_45"
> Windows 7 64 bit
> Reporter: Claude-Alain
>
> Regarding this subject, a fix has been done (CXF-3662) but I have some
> reasons to think that it has not been done in the right way.
> In the given example, there is one normal response (status code = 200) and
> one response which is an error (status code = 400). In that case the fix is
> doing the right thing, the first type is take into account and the error type
> can be managed by an exception mapper (from what I see in the documentation
> of RESTEasy and Jersey).
> But in the case we introduce another response like shown in the example just
> below:
> {code:xml}
> <method name="GET" id="getUserDefaults">
> <doc>Gets default user configuration values.</doc>
> <response status="200">
> <representation mediaType="application/xml"
> element="fmc:userDefaults" />
> </response>
> <response status="204">
> <representation mediaType="application/xml"
> element="fmc:noContent" />
> </response>
> <response status="400">
> <representation mediaType="application/xml"
> element="fmc:errorList" />
> </response>
> </method>
> {code}
> then the return type for the corresponding method in the generated interface
> will be "userDefaults". Since a Java method can only return an object of a
> given type then it will never be possible to return an object of type
> "noContent".
> So I think the only way to solve this case is to return a type
> "javax.ws.rs.core.Response".
> The only workaround I found is to remove the type type specified in the
> response to make sure that we always have a return type "Response".
--
This message was sent by Atlassian JIRA
(v6.2#6252)
