You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@cxf.apache.org by "Christos Fragoulides (JIRA)" <ji...@apache.org> on 2011/09/09 15:17:10 UTC
[jira] [Created] (CXF-3797) WADL Generator improvements
WADL 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
Fix For: 2.5
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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CXF-3797) WADL2Java Generator improvements
Posted by "Sergey Beryozkin (Resolved) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sergey Beryozkin resolved CXF-3797.
-----------------------------------
Resolution: Fixed
Fix Version/s: 2.4.4
> 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.4.4, 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
[jira] [Issue Comment Edited] (CXF-3797) WADL2Java Generator
improvements
Posted by "Sergey Beryozkin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111315#comment-13111315 ]
Sergey Beryozkin edited comment on CXF-3797 at 9/21/11 9:32 PM:
----------------------------------------------------------------
Hi
I've applied most of the fixes with some modifications. The only two ones which haven't been applied yet are these :
+ /**
+ * Christos Fragoulides / 2011-09-08: A method element may contain many representation
+ * elements, each one defining a different request body element.
- going to work on this one
and
- if (!isRoot) {
+ /**
+ * Christos Fragoulides / 2011-09-06: Fixing the following lines. Path annotation
+ * should only be applied to resource elements, not method elements.
Can you please use the snapshot and see if this last one is still an issue, and if yes then point to a specific section in WADL then I can try ?
Also please confirm on your side if other fixes result in a better generated code
Many thanks, Sergey
was (Author: sergey_beryozkin):
Hi
I've applied most of the fixes with some modifications. The only two ones which haven't been applied yet are these :
+ /**
+ * Christos Fragoulides / 2011-09-08: A method element may contain many representation
+ * elements, each one defining a different request body element.
- going to work on this one
and
- if (!isRoot) {
+ /**
+ * Christos Fragoulides / 2011-09-06: Fixing the following lines. Path annotation
+ * should only be applied to resource elements, not method elements.
Can you please check the source if this last one is still an issue, and if then point to a specific section in WADL then I can try ?
Also please check if other fixes result in a better generated code
Many thanks, SErgey
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-3797) WADL2Java Generator improvements
Posted by "Christos Fragoulides (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Christos Fragoulides updated CXF-3797:
--------------------------------------
Attachment: SourceGenerator_patch2.patch
Second patch.
> 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
[jira] [Commented] (CXF-3797) WADL2Java Generator improvements
Posted by "Sergey Beryozkin (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13122663#comment-13122663 ]
Sergey Beryozkin commented on CXF-3797:
---------------------------------------
Hi, is there a public link available to a Rackspace cloud server WADL ?
Their Cloud Server API guide has a link to an old version of WADL, thanks...
> 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.4.4, 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
[jira] [Commented] (CXF-3797) WADL2Java Generator improvements
Posted by "Christos Fragoulides (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13101284#comment-13101284 ]
Christos Fragoulides commented on CXF-3797:
-------------------------------------------
You're welcome.
The patch have been created against the source I've checked out from trunk. The version in the pom is 2.5.0-SNAPSHOT.
Are you referring to CXF-3759? When I first started checking the code, I did it with 2.4.2 sources and this issue was in place.
In the latest source the issue had been fixed, but it was a different case (multiple <response> elements with one status each). The patch I've attached deals with multiple status codes defined in the @status attribute of a single <response> element.
See this link for details: http://www.w3.org/Submission/wadl/#x3-200002.10
I will attach the full file so you can diff easier with the latest one.
> 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
> Labels: patch
> Fix For: 2.5
>
> Attachments: 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-3797) WADL2Java Generator improvements
Posted by "Christos Fragoulides (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13120439#comment-13120439 ]
Christos Fragoulides commented on CXF-3797:
-------------------------------------------
Hi, thanks for committing these changes.
About the OK response: I have revisited the specification and to my understanding the following response codes allow an entity-body in the response: 200, 201, 202, 203. Since there can be an entity-body, there can be a representation. Of course I might be missing something since I'm not an expert on this field.
If we ignore the issue with the methods having multiple representations(I edited the WADL as described in my previous comment to workaround this) and the minor issue with OK response codes (can be fixed the same way), I am now able to use the 2.5.0-SNAPSHOT to generate working code without problems.
Many thanks,
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, 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
[jira] [Commented] (CXF-3797) WADL2Java Generator improvements
Posted by "Sergey Beryozkin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13101256#comment-13101256 ]
Sergey Beryozkin commented on CXF-3797:
---------------------------------------
Many thanks for the patch.
If you get a chance: please try to create a patch against the latest source - I recall making some changes to do with multiple status codes;
I can handle the related conflict manually too, not a problem
> 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
> Labels: patch
> Fix For: 2.5
>
> Attachments: 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-3797) WADL2Java Generator improvements
Posted by "Sergey Beryozkin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13111315#comment-13111315 ]
Sergey Beryozkin commented on CXF-3797:
---------------------------------------
Hi
I've applied most of the fixes with some modifications. The only two ones which haven't been applied yet are these :
+ /**
+ * Christos Fragoulides / 2011-09-08: A method element may contain many representation
+ * elements, each one defining a different request body element.
- going to work on this one
and
- if (!isRoot) {
+ /**
+ * Christos Fragoulides / 2011-09-06: Fixing the following lines. Path annotation
+ * should only be applied to resource elements, not method elements.
Can you please check the source if this last one is still an issue, and if then point to a specific section in WADL then I can try ?
Also please check if other fixes result in a better generated code
Many thanks, SErgey
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-3797) WADL2Java Generator improvements
Posted by "Christos Fragoulides (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Christos Fragoulides updated CXF-3797:
--------------------------------------
Attachment: SourceGenerator.java
Full source of modified SourceGenerator.java
> 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
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (CXF-3797) WADL2Java Generator
improvements
Posted by "Christos Fragoulides (Issue Comment Edited) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13115142#comment-13115142 ]
Christos Fragoulides edited comment on CXF-3797 at 9/27/11 2:35 AM:
--------------------------------------------------------------------
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 ServerID {
// 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"})
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
was (Author: xfrag):
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
[jira] [Commented] (CXF-3797) WADL2Java Generator improvements
Posted by "Sergey Beryozkin (Commented) (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (CXF-3797) WADL2Java Generator improvements
Posted by "Sergey Beryozkin (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13121063#comment-13121063 ]
Sergey Beryozkin commented on CXF-3797:
---------------------------------------
OK, I updated the generator to support multiple in XML representations for a given method.
By default, a single method with a single javax.xml.transform.Source in parameter will be created in such cases - because on the server side it will produce a non-compliant code otherwise. However if you have a case where the server is not implemented with JAX-RS and effectively you are only interested in consuming that services then setting a "supportMultipleXmlReps" switch will do it for you, I think it's a good compromise :-)
Many thanks for your input. I'm also going to blog about this effort.
> 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.4.4, 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
[jira] [Assigned] (CXF-3797) WADL2Java Generator improvements
Posted by "Sergey Beryozkin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sergey Beryozkin reassigned CXF-3797:
-------------------------------------
Assignee: Sergey Beryozkin
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-3797) WADL2Java Generator improvements
Posted by "Christos Fragoulides (Commented) (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (CXF-3797) WADL2Java Generator improvements
Posted by "Sergey Beryozkin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13112663#comment-13112663 ]
Sergey Beryozkin commented on CXF-3797:
---------------------------------------
Ok, all the fixes with updates are now in except the two ones I mentioned in the prev comment.
1. Methods having multiple in XML representations
That would generate a valid code - but it won't work on the server side, in the JAX-RS impl, the selection algorithm will be unpredictable. But will work for proxies. Not sure how to address it yet, may be I can introduce a 'lax' switch which if set will hint to the generator that creating methods like
POST
@Path("/a")
void method1(A body);
POST
@Path("/a")
void method1(B body);
is ok...
2. I did not understand the comment about @Path annotations and elements identifying wadl:method elements. Please clarify
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-3797) WADL2Java Generator improvements
Posted by "Christos Fragoulides (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Christos Fragoulides updated CXF-3797:
--------------------------------------
Attachment: rackspace.xml
Modified working version of Rackspace's Cloud Servers API WADL.
> 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.4.4, 2.5
>
> Attachments: SourceGenerator.java, SourceGenerator_patch2.patch, rackspace.xml, 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
[jira] [Updated] (CXF-3797) WADL2Java Generator improvements
Posted by "Christos Fragoulides (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Christos Fragoulides updated CXF-3797:
--------------------------------------
Attachment: wadl2java_patch.zip
Patch file, WADL documents and the imported XSD files.
> 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
> Labels: patch
> Fix For: 2.5
>
> Attachments: 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CXF-3797) WADL2Java Generator improvements
Posted by "Christos Fragoulides (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Christos Fragoulides updated CXF-3797:
--------------------------------------
Summary: WADL2Java Generator improvements (was: WADL Generator improvements)
> 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
> Labels: patch
> Fix For: 2.5
>
>
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CXF-3797) WADL2Java Generator improvements
Posted by "Christos Fragoulides (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CXF-3797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13124277#comment-13124277 ]
Christos Fragoulides commented on CXF-3797:
-------------------------------------------
Hi,
I'm glad the generator is now fully functional (at least in respect with the issues discussed here). Hope this effort will help others start consuming RESTful web services easier.
Unfortunately, Rackspace only provides the old version that you mentioned. The fist thing I done when started was to edit this WADL and make it conform with the latest version, hoping that the generator will do the rest :)
I will attach the WADL I'm currently working with. Maybe it will be a good idea to send a copy to Rackspace too.
Please send me an email when you'll have the blog post written, I'm interested in reading it.
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.4.4, 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