[
https://issues.apache.org/jira/browse/CXF-7547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16243791#comment-16243791
]
Sergey Beryozkin edited comment on CXF-7547 at 11/8/17 12:04 PM:
-----------------------------------------------------------------
I've updated that test file with a new resource referencing the same post
method and also changing its id from "addBook" and "post":
{code:xml}
<method name="POST" id="post">
<request>
<representation mediaType="application/xml"
element="prefix1:thebook"/>
</request>
</method>
<resource_type id="main-resource">
<resource path="/books/{bookid}">
<param name="bookid" style="template" type="xs:int"/>
<method href="#post"/>
</resource>
<resource path="/books/id/{bookid}">
<param name="bookid" style="template" type="xs:int"/>
<method href="#post"/>
</resource>
</resource_type>
{code}
Before your patch I see "postBooksbookid" and "postBooksidbookid", and while a
bit more effort could've gone into making the names a bit more friendly to the
eye (ex, capitalizing the 1st letter of every new path segment), I think it is
still much more descriptive then "post" and "post2" which is what I get after
applying your patch.
I'm not going to support this patch - because indeed it can break the users'
code and having a numbering scheme is the very last resource that the generator
tries to avoid the compilation failure.
To be honest I don't understand why won't you do a new patch based on the
introduction of the new option - it will get you what is needed in your case
and most importantly it will be safe as well.
was (Author: sergey_beryozkin):
I've updated that test file with a new resource referencing the same post
method and also changing its id from "addBook" and "post":
{code:xml}
<method name="POST" id="post">
<request>
<representation mediaType="application/xml"
element="prefix1:thebook"/>
</request>
</method>
<resource_type id="main-resource">
<resource path="/books/{bookid}">
<param name="bookid" style="template" type="xs:int"/>
<method href="#post"/>
</resource>
<resource path="/books/id/{bookid}">
<param name="bookid" style="template" type="xs:int"/>
<method href="#post"/>
</resource>
</resource_type>
{code}
Before your patch I see "postBooksbookid" and "postBooksidbookid", and while a
bit more effort could've gone into making the names a bit more friendly to the
eye (ex, capitalizing the 1st letter of every new path segment), I think it is
still much more descriptive then "post" and "post2" which is what I get after
applying your patch.
I'm not going to support this patch - because indeed it can break the users'
code and having a numbering scheme is then very last resource that the
generator tries to avoid the compilation failure.
To be honest I don't understand why won't you do a new patch based on the
introduction of the new option - it will get you what is needed in your case
and most importantly it will be safe as well.
> 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)
