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

Sergey Beryozkin commented on CXF-3797:
---------------------------------------

Hi, thanks for the comments and the 2nd patch.

The bug with a duplicate parameter has been fixed. I spent quite a lot of time 
thinking if it would affect a server side code or not. If we have a pathparam 
in a subresource locator then a locator impl must have setters or constructors 
to carry these values along and these are not generated at the moment. But 
having them on subresource methods only can be easily done by introducing a 
resource wrapper with a single forward slash, so I thought it would work ok.

Fixed the issue with primitives - at the moment it's restricted to Queries 
which have no "required" attribute or have a "repeating" attributes.

Re OK response: without 200 we won't have a representation, right ? So I'm 
thinking that if it is anything but 200 then no point of generating a 
wadl:response...

Re methods with multiple (xml) representations, not sure yet what to do. On the 
server side that would produce a code which will work unpredictably in case of 
JAX-RS - may be we should generate Source in that case...  
  
                
> 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, SourceGenerator_patch2.patch, 
> 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

        

Reply via email to