[
https://issues.apache.org/jira/browse/CXF-5706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claude-Alain updated CXF-5706:
------------------------------
Description:
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".
was:
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 on 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".
> 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)
