cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail S (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CXF-6064) Improve WADL Generator Extensibility for ID generation
Date Thu, 04 Dec 2014 04:47:12 GMT

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

Mikhail S commented on CXF-6064:
--------------------------------

Thanks for addressing it. 

One thing that we did notice is that by default if XmlRootElement is specified with full qname,
the generated ID in the WADL is incompliant with the WADL specification because of {} generated
by default. 

The ID element is xs:ID which should be a valid NCName. It is reasonable to expect that the
IDs generated by CXF out of the box would be compliant. 

I have not verified if the applied fix will address it entirely, I assume at least we would
be able to work around. I assume I can create a separate issue on that, since the original
one is fixed. 

Please let me know if you see a better way of handling it. 

Thanks,
Mikhail

> Improve WADL Generator Extensibility for ID generation
> ------------------------------------------------------
>
>                 Key: CXF-6064
>                 URL: https://issues.apache.org/jira/browse/CXF-6064
>             Project: CXF
>          Issue Type: Improvement
>          Components: JAX-RS
>    Affects Versions: 3.0.1
>            Reporter: Mikhail S
>            Assignee: Sergey Beryozkin
>             Fix For: 3.1.0, 3.0.3
>
>
> WADLGenerator class is not extensible and prevents extensions for simple customizations.
> Example: We would like to use custom IDs on the resource and methods. The mechanism provided
in CXF requires to either use {{@XmlRootElement}} or rely on the default mechanism which will
use fully qualified class name as the resource ID. 
> Our beans are annotated with {{@WebService}} annotation (and other metadata) so it would
only require a slight extension of the WADL generator to utilize a different strategy. 
> However, this task becomes quite unattainable given the current design of the WADLGenerator.
It basically requires to create (and maintain) a copy of the class that extends WADL generator.

> In general, WADL generator extensibility could be reviewed (at least private vs protected
methods, allowing additional strategy injection for ID generation that defaults to some built-in
strategy). 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message