[
https://issues.apache.org/jira/browse/CXF-7547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16241906#comment-16241906
]
Evaristo Wychoski Benfatti edited comment on CXF-7547 at 11/7/17 12:13 PM:
---------------------------------------------------------------------------
Two more points:
# Could you please provide me more details about "Paths were not added
initially, only at a later stage."? The actual behavior it just appends the
path fragment to method name when name and id are equals, for others cases the
normal behavior is apply the same id that is present in the wald, in other
words, for 'get'.equals('get'), 'post'.equals('post') and other similar cases
apply, but 'get'.equals('search') and 'post'.equals('insert') does not apply,
is this behavior right? The same behavior that you expressed it'd happen to all
cases in my opinion. I am basing on it to propose such patch. Could you plese
help on this?
# About test cases could you please help me on producing it? Today there is not
any test case that portray such scenario, the patch does not fail to any actual
test, because of this and trying standardizing the way that java is generated
from wald I proposed the patch.
was (Author: evaristowb):
Two more points:
# Could you please provide me more details about "Paths were not added
initially, only at a later stage."? The actual behavior it just appends the
path fragment to method name when name and id are equals, for others cases the
normal behavior is apply the same id that is present in the wald, in other
words, for 'get'.equals('get'), 'post'.equals('post') and other similar cases
apply, but 'get'.equals('search') and 'post'.equals('insert') does not apply,
is this behavior right? The same behavior that you expressed it'd happen to all
cases in my opinion. I am basing on it to propose such patch. Could you plese
help on this?
# About test cases could you please help me on producing it? Today there is not
any test case that portray such scenario, the patch does not fail to any actual
test, because of this and trying standardizing the way that java is generated
from wald I propose the patch.
> Problem to generate Java from WADL file when method id defined
> ---------------------------------------------------------------
>
> Key: CXF-7547
> URL: https://issues.apache.org/jira/browse/CXF-7547
> Project: CXF
> Issue Type: Bug
> Components: JAX-RS
> Affects Versions: 3.1.14, 3.2.1
> Environment: All Plataforms
> Reporter: Evaristo Wychoski Benfatti
> Priority: Minor
> Labels: patch
>
> The following code base
> {code:java}
> @Path("/baz")
> public class Baz {
> @GET
> @Path("/foo/{id}")
> @Produces("text/plain")
> public String get(@PathParam int id);
> }
> {code}
> generates a similar wadl as follow as result of {{Java2Wadl}} process:
> {code:xml}
> <application xmlns="http://wadl.dev.java.net/2009/02";
> xmlns:xs="http://www.w3.org/2001/XMLSchema";>
> <resources base="/baz" id="Baz">
> <resource path="/foo/{id}" id="get">
> <param name="id" style="template" type="xs:int"/>
> <method name="GET" id="get">
> <response>
> <representation mediaType="text/plain">
> <param name="result" style="plain" type="xs:string"/>
> </representation>
> </response>
> </method>
> </resource>
> </resources>
> </application>
> {code}
> When we run after the {{Wadl2Java}} process against previous wadl as input,
> the process takes to the following java definition class as output:
> {code:java}
> @Path("/baz")
> public class Baz {
> @GET
> @Path("/foo/{id}")
> @Produces("text/plain")
> public String getId(@PathParam int id);
> }
> {code}
> According to
> {{tools/wadlto/jaxrs/src/main/java/org/apache/cxf/tools/wadlto/jaxrs/SourceGenerator.java}}
> a wadl method element generates the path as complement to the java method
> name when it does not have an id atribute or when it is the even value of
> name atribute.
> When id is not defined this behavior is right, but when both of atributes are
> defined in order to get the even class used to generate the wadl file as
> result of {{Wadl2Java}} process this is not.
> The solution to enable creating the even code is check if the id is present
> or not at wadl file as follow:
> {code:java}
> // Line 796 instead of this
> if (methodNameLowerCase.equals(genMethodName)) {
> // this code
> if (methodNameLowerCase.equals(genMethodName) && methodNameLowerCase
> == id) {
> {code}
> The above code check if methodNameLowerCase is the even reference of id, only
> in this case, the normal behavior is applied.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
