[
https://issues.apache.org/jira/browse/CXF-7547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16240836#comment-16240836
]
Evaristo Wychoski Benfatti edited comment on CXF-7547 at 11/6/17 8:32 PM:
--------------------------------------------------------------------------
Following the answers:
{quote}*May be I'm confused, but "if (methodNameLowerCase.equals(genMethodName)
&& methodNameLowerCase == id) {" reads to me that "add a path fragment if it is
something like 'get'.equals('get') and id.equals('get')", i.e. add a path
fragment only if a method name and id match ?*{quote}
The condition check proposed "methodNameLowerCase == id" evaluates if the id
which was previously set in the code through method calling {{getMethodId()} is
the same reference still. In other words id is not defined at wadl being the
methodNameLowerCase itself. The line
{tools/wadlto/jaxrs/src/main/java/org/apache/cxf/tools/wadlto/jaxrs/SourceGenerator.java#L720}
does such attribution you can see as follows:
{code:java}
String id = getMethodId(methodEl, methodNameLowerCase);
{code}
As it can be seen bellow, the default method behavior returns
methodNameLowerCase itself if id is not present.
{code:java}
private String getMethodId(Element methodEl, String methodNameLowerCase) {
String id = methodEl.getAttribute("id");
if (id.length() == 0) {
id = methodNameLowerCase;
}
return id;
}
{code}
{quote}*FYI, even when the id is provided it can still be needed to add path
bits. There could be multiple methods with id="get". I'm pretty sure there were
cases like that when multiples get() or similar were generated leading to the
compiler errors. May be in cases where a WADL was imported, with the same
method referenced from diff places.*{quote}
_"FYI, even when the id is provided it can still be needed to add path bits."_
May you give me more details about such cases? My understanding is that there
could not be different method tags with same names and ids differents to the
same resource. By the way, this the patch does not affect such cases, following
the proposed patch by default the code adds a path increment when there are
more than one equal methods avoiding such problem.
_"There could be multiple methods with id="get""_
Yes there can be, but the proposed patch does not change this behavior, it
simply propose creating the method name in java class according to id if it
exists. Based on OO concepts there is not any restriction with methods name,
since it is overloaded.
_"May be in cases where a WADL was imported, with the same method referenced
from diff places."_
May you give me more details about this too?
{quote}*And can you explain why do you need a complete match in the
WADl-Java-Wadl case ? FYI you can configure CXF to serve the WADL doc without
it being auto-generated*{quote}
Our scenario is using the wadl generated from source to generate the client
artifacts to make remote proxy calls, in the similar way which is done with
wsdl and SOAP. The contract generated either wadl or wsdl is part of process to
create the stubs those after are used as remote proxies.
was (Author: evaristowb):
Following the answers:
{quote}May be I'm confused, but "if (methodNameLowerCase.equals(genMethodName)
&& methodNameLowerCase == id) {" reads to me that "add a path fragment if it is
something like 'get'.equals('get') and id.equals('get')", i.e. add a path
fragment only if a method name and id match ?{quote}
The condition check proposed "methodNameLowerCase == id" evaluates if the id
which was previously set in the code through method calling {{getMethodId()} is
the same reference still. In other words id is not defined at wadl being the
methodNameLowerCase itself. The line
{tools/wadlto/jaxrs/src/main/java/org/apache/cxf/tools/wadlto/jaxrs/SourceGenerator.java#L720}
does such attribution you can see as follows:
{code:java}
String id = getMethodId(methodEl, methodNameLowerCase);
{code}
As it can be seen bellow, the default method behavior returns
methodNameLowerCase itself if id is not present.
{code:java}
private String getMethodId(Element methodEl, String methodNameLowerCase) {
String id = methodEl.getAttribute("id");
if (id.length() == 0) {
id = methodNameLowerCase;
}
return id;
}
{code}
{quote}FYI, even when the id is provided it can still be needed to add path
bits. There could be multiple methods with id="get". I'm pretty sure there were
cases like that when multiples get() or similar were generated leading to the
compiler errors. May be in cases where a WADL was imported, with the same
method referenced from diff places.{quote}
_"FYI, even when the id is provided it can still be needed to add path bits."_
May you give me more details about such cases? My understanding is that there
could not be different method tags with same names and ids differents to the
same resource. By the way, this the patch does not affect such cases, following
the proposed patch by default the code adds a path increment when there are
more than one equal methods avoiding such problem.
_"There could be multiple methods with id="get""_
Yes there can be, but the proposed patch does not change this behavior, it
simply propose creating the method name in java class according to id if it
exists. Based on OO concepts there is not any restriction with methods name,
since it is overloaded.
_"May be in cases where a WADL was imported, with the same method referenced
from diff places."_
May you give me more details about this too?
{quote}And can you explain why do you need a complete match in the
WADl-Java-Wadl case ? FYI you can configure CXF to serve the WADL doc without
it being auto-generated{quote}
Our scenario is using the wadl generated from source to generate the client
artifacts to make remote proxy calls, in the similar way which is done with
wsdl and SOAP. The contract generated either wadl or wsdl is part of process to
create the stubs those after are used as remote proxies.
> 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)
