cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christos Fragoulides (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CXF-3797) WADL2Java Generator improvements
Date Tue, 27 Sep 2011 02:34:12 GMT

    [ https://issues.apache.org/jira/browse/CXF-3797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13115142#comment-13115142
] 

Christos Fragoulides commented on CXF-3797:
-------------------------------------------

Hi,

Nice to hear you've merged the updates.
For 1) another possible approach is the following:

POST
@Path("/a")
void method1_A(A body);

POST
@Path("/a")
void method1_B(B body);

By appending the body type to the method name, it will be clear on the server side what has
to be implemented and on the client side which method to use.

Another way is to edit the WADL and spit the method that accepts multiple representations
in to multiple methods(with different IDs) accepting one of the representations each. But
this makes things harder for the
developer(when working with proxies) since the problem has to be identified and the solution
has to be known.


For 2):
the comment about @Path annotations and the corresponding code changes do not longer apply
with the
latest version of the source code. I created a new patch, containing this fix and two new
ones, explained below.
--------------------------
As stated in the specification(see http://www.w3.org/Submission/wadl/#x3-270002.12.2 Table
1), <param> elements
having their @style attribute set to 'template' should be used for substituting variables
in the @path attribute
of the parent <resource> element.

Consider the following WADL example:

<resource path="servers" id="Servers">
    <resource path="{serverId}" id="ServerID">
        <param type="xsd:int" style="template" name="serverId"/>
        <method id="getServer" name="GET">
          ...
        </method>
    </resource>
</resource>

Currently the SourceGenerator will generate the following interfaces for Servers and ServerID
resources:

public interface Servers {

    @Path("{serverId}")
    ServerIDResource getServerID(@PathParam("serverId") Integer serverId);

}

public interface ServerIDResource {

    // PathParam is redundant here, it is already specified in getServerID() method of Servers.
    // having the parameter here will result in the following path: "/servers/{serverId}/{serverId}
    // instead of "/servers/{serverId}
    @GET
    @Produces({"application/xml", "application/json" })
    Server getServer(@PathParam("serverId") Integer serverId);

}

On the other hand, if the subresource did not had its @id attribute set, like this:

<resource path="servers" id="Servers">
    <resource path="{serverId}">
        <param type="xsd:int" style="template" name="serverId"/>
        <method id="getServer" name="GET">
          ...
        </method>
    </resource>
</resource>

The following interface is generated:

public interface Servers {

    // PathParam is needed here, since the method belongs to a subresource with no id set
    // and the path parameter is necessary. 
    @GET
    @Produces({"application/xml", "application/json" })
    @Path("{serverId}")
    Server getServer(@PathParam("serverId") Integer serverId);

}

----------------------------------
The second fix in the patch is for the getOKResponse() method. A response should be taken
as successful
for a number of response codes in the 2XX range.

----------------------------------
Finally I made a change in an attempt to support optional parameters in methods corresponding
to primitive
Java types.
If a <request> has an optional <param> defined, like the one below:
<param type="xsd:long" style="query" name="changes-since"/>
The generator will create a method accepting a Java int, so the method will always have to
be called with
a value specified for this parameter, effectively making it a required parameter.

With the fix applied, the method will accept a Java Integer, allowing to call it providing
null as the value.
I made some tests with proxies and it seems to work fine, don't know what happens server-side
though.

Kind Regards,
Christos
                
> WADL2Java Generator improvements
> --------------------------------
>
>                 Key: CXF-3797
>                 URL: https://issues.apache.org/jira/browse/CXF-3797
>             Project: CXF
>          Issue Type: Improvement
>          Components: JAX-RS
>            Reporter: Christos Fragoulides
>            Assignee: Sergey Beryozkin
>              Labels: patch
>             Fix For: 2.5
>
>         Attachments: SourceGenerator.java, wadl2java_patch.zip
>
>
> Given a relatively complex WADL file (such as the one provided by Rackspace Cloud Servers
API), JAX-RS WADL2Java Generator has many difficulties generating the proper Java classes.
> To name a few:
> - Generated method parameter names may be invalid. For example a header parameter named
'X-Auth-Token' will not have the dashes removed before being converted to a Java method parameter.
This results in invalid generated source.
> - @Produces annotation is not applied to methods, when the corresponding <response>
element contains more that one representation elements.
> - Resolved XML-schemata(from the <grammars> section of the WADL) may contain included
schemata.
> - The status attribute of the <response> element may contain a list of status codes.
The generator is expecting none or a single entry. Also the generator looks only for HTTP
status 200, while there are more valid codes, like 203.
> - The generated class names may collide with names of JAXB generated classes. For example
a resource named 'Limits' may need to import a JAXB generated class also named 'Limits' this
will trigger compilation errors.
> We were trying to use the generator in order to create and use CXF Client Proxies for
the RESTful web service mentioned above. This was necessary for us since we need to use the
API for managing Radiojar, the main project we are currently working on.
> I ended up checking out the source for JAX-RS Frontend and trying to fix the bugs in
SourceGenerator.
> Finally I managed to address the problems, so I will attach a patch to this issue, along
with the WADL file and the imported XSDs.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message