[ 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)