[jira] [Commented] (CXF-5916) WADL contains wrong parameter name for parameter beans

["Enrico Scheider (JIRA)" <ji...@apache.org>]

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

Enrico Scheider commented on CXF-5916:
--------------------------------------

Hi Sergey,

many thx for answering and resolving immediately...
Truth be told: i had'nt had the new @PeanParam from JAX-RS 2.0 in mind yet - maybe a sort of ' forgot about something due to an allday new frameworks with massive new feature's hell ;-)' - so thx for this hint as well.

As you said, WadlGenerator doesn't support this yet, so by now it's not a real option to use this new jax-rs-spec feature. As far as i understood the new @BeanParam's they are - simple said - just an collection and delegation to well-known jax-rs 1.0 @*Param-annos. So a starting point to support this might be here:

{code:title=WadlGenerator.java|borderStyle=solid}
// cxf 3.0.1, line=663
private void writeParam(StringBuilder sb, Parameter pm, OperationResourceInfo ori, boolean isJson) {
        Method method = getMethod(ori);
        Class<?> type = method.getParameterTypes()[pm.getIndex()];
        if (!"".equals(pm.getName())) {
            // write standard jax-rs 1.0 annotated parameter
            doWriteParam(ori,
                         sb,
                         pm, 
                         type, 
                         method.getGenericParameterTypes()[pm.getIndex()], 
                         pm.getName(),
                         method.getParameterAnnotations()[pm.getIndex()], 
                         isJson);
        } else {
            // cxf param bean support here
            List<Class<?>> parentBeanClasses = new LinkedList<Class<?>>();
            parentBeanClasses.add(type);
            doWriteBeanParam(ori, sb, type, pm, null, parentBeanClasses, isJson);
        }
    }
{code}
Of course i don't know all the hard inner details of WadlGenerator by now - but maybe there is a way to provide all required parameter info's before, independent of cxf-param bean, new jax-rs 2.0 @BeanParam or jax-rs-1.0 @*Param. So we could always perform the 'doWriteParam' part here (something like: treat each method param as jax-rs 1.0 @*Param mimic)?

cheers , Enrico


> WADL contains wrong parameter name for parameter beans
> ------------------------------------------------------
>
>                 Key: CXF-5916
>                 URL: https://issues.apache.org/jira/browse/CXF-5916
>             Project: CXF
>          Issue Type: Bug
>          Components: JAX-RS
>    Affects Versions: 3.0.0, 3.0.1
>            Reporter: Enrico Scheider
>            Assignee: Sergey Beryozkin
>            Priority: Minor
>             Fix For: 2.7.13, 3.0.2, 3.1.0
>
>
> I'm using auto generated wadl from jax-rs annotated service beans in conjunction with cxf parameter bean extension (cool feature ;-), thx. alot). Wenn accessing the auto generated wadl (url extension ?_wadl) the resulting parameter names are always lower cased and do not reflect e.g. real path variable names when using the parameter bean extension. Assume the following example code (annotated service, sample parameter bean, relevant wadl snippets)...:
> {code:title=MyService.java|borderStyle=solid}
> @Path("sample/{camelCasedVariable}")
> @Produces({MediaType.APPLICATION_JSON,MediaType.APPLICATION_XML})
> public class MyService {
>     @GET
>     @Path("test1/{userId}")
>     public Response test1(@PathParam("camelCasedVariable") final String variable, @PathParam("userId") final String id) {
>         return Response.accepted().build();
>     }
>     @GET
>     @Path("test2/{userId}")
>     public Response test2(@PathParam("") final SampleBean bean) {
>         return Response.serverError().build();
>     }
> }
> {code}
> {code:title=SampleBean.java|borderStyle=solid}
> public class SampleBean {
>     private String camelCasedVariable;
>     private String userId;
>     public String getCamelCasedVariable() {
>         return camelCasedVariable;
>     }
>     public void setCamelCasedVariable(final String camelCasedVariable) {
>         this.camelCasedVariable = camelCasedVariable;
>     }
>     public String getUserId() {
>         return userId;
>     }
>     public void setUserId(final String userId) {
>         this.userId = userId;
>     }
> }
> {code}
> ... resulting in the following wadl snippet, shortened:
> {code:xml}
> <!-- intro, grammer,... -->
> <resources base="http://localhost:8080/services/">
>     <resource path="/sample/{camelCasedVariable}/test1/{userId}>
>         <param name="camelCasedVariable" style="template" type="xs:string">
>         <param name="userId" style="template" type="xs:string">
>     </resource>
>     <resource path="/sample/{camelCasedVariable}/test2/{userId}>
>         <param name="camelcasedvariable" style="template" type="xs:string">
>         <param name="userid" style="template" type="xs:string">
>     </resource>
> </resources>
> {code}
> In test1 standard jax-rs annotations have been used and generated wadl part is ok. In test2 cxf-parameter bean has been used, resulting in lowercased variable names which seems to be incorrect. Same occurs when using parameter beans in QueryParams, probably on other jax-rs variable type as well (Matrix,Form etc.).
> I've checked the WadlGenerator.java class and found the following referenced code snippet from InjectionUtils.java (cxf-rt-frontend), maybe this is a starting hint for your analysis:
> {code:title=InjectionUtils.java|borderStyle=solid}
> //... 
> public static Map<Parameter, Class<?>> getParametersFromBeanClass(Class<?> beanClass, 
>                                                                       ParameterType type,
>                                                                       boolean checkIgnorable) {
>     // some stuff to detect public setter methods...
>    // cxf-3.0.0: line1219 | cxf.3.0.1 line 1224
>    String propertyName = methodName.substring(minLen).toLowerCase();
>   // this propertyName is used as Parameter model name later on...
>   params.put(new Parameter(type, propertyName), m.getReturnType());
> {code}
> From my point of view the propertyName should not be lowercased here.



--
This message was sent by Atlassian JIRA
(v6.2#6252)