Query parameter in WADL is missing a dot ( Was : JAX-RS : initial WADL support)

[Sergey Beryozkin <sb...@progress.com>]

Another thing, I suspect is a bug, is a dot notation again.
If I have a principal.username the WADLGenerator only outputs principal,
which is what SoapUI sees, maing it hard to form a POST request..

S.B I did a quick test with a method containing
@QueryParam("principal.user") and the generated WADL had a proper value.
Perhaps SoapUI is missing it ?
 
However, having  

QueryParam("") QueryBean, where QueryBean is declared like this :

public static class QueryBean {
        private int a;
        private int b;
        private QueryBean2 bean;
        
        public int getA() {
            return a;
        }
        
        public int getB() {
            return b;
        }
        
        public QueryBean2 getC() {
            return bean;
        }
        
        public void setC(QueryBean2 c) {
            bean = c;
        }
    }
    
    public static class QueryBean2 {
        private int a;
        private int b;
        private QueryBean3 bean;
        
        public int getA() {
            return a;
        }
        
        public int getB() {
            return b;
        }
        
        public QueryBean3 getD() {
            return bean;
        }
        
        public void setD(QueryBean3 d) {
            bean = d;
        }
    }
    
    public static class QueryBean3 {
        private int a;
        private int b;
        
        public int getA() {
            return a;
        }
        
        public int getB() {
            return b;
        }
    } 

reproduced the issue, 6 query parameters were generated, with the names
of the parent beans being missed. It is fixed on mainline now. So you'll
get 

<param name="a" style="query" type="xs:int"/>
<param name="b" style="query" type="xs:int"/>
<param name="c.a" style="query" type="xs:int"/>
<param name="c.b" style="query" type="xs:int"/>
<param name="c.d.a" style="query" type="xs:int"/>
<param name="c.d.b" style="query" type="xs:int"/>


Cheers, Sergey  

Sergey Beryozkin-2 wrote:
> 
> Hi,
> 
> This is a bug. The workaround is use @Path("execute"), it won't affect
> the dispatching logic in any way.
> 
> It is time to pay some more attention to the WADLGenerator...
> 
> Thanks, Sergey
> 
> -----Original Message-----
> From: vickatvuuch [mailto:vlisovsky@gmail.com] 
> Sent: 11 December 2009 15:29
> To: users@cxf.apache.org
> Subject: Re: JAX-RS : initial WADL support
> 
> 
> Was about to post a new entry on WADL when noticed this hot post..
> I'm debugging a bug in the WADL generator, which results in extra
slash
> /
> in the Url and once loaded into soap UI make it not executable unless 
> url is fixed up by hand.
> Here is my config:
> 
> <jaxrs:server address="/v1/rest/Foo">
> 
> The Impl:
> @Path("")
> public class FooWServiceImpl
> 
> Method:
>   @POST
>   @Path("/execute")
> 
> This results in WADL with a Url such as:
/services/v1/rest/Foo//execute
> 
> Notice extra slash after Foo.
> 
> Wonder if anyone already seen this or if there is something wrong with
> the
> way I annotated it?
> 
> Thanks,
> -Vitaly
> 
> 
> Sergey Beryozkin-2 wrote:
>> 
>> Hi
>> 
>> CXF JAX-RS now supports the auto-generation of WADL for JAX-RS
> endpoints
>> (trunk, 2.2.3-SNAPSHOT).
>> The whole tree/graph will be described in a generated instance. Note
> that
>> JAX-RS subresources are supposed to be late-resolved, so I'd
recommend
>> using annotated interfaces for subresources and an
>> enableStaticResolution=true property. At the moment I've decided to
> stay
>> away from from supporting WADl for those subresources whicg are
> resolved
>> late - will be very easy to support if really needed. Schemas will be
>> generated for JAXB-annotated types.
>> 
>> I'd appreciate if users could experiment a bit with the latest
> SNAPSHOTS
>> and provide the feedback and help us to improve whatever we have in
> time
>> for 2.2.3. I don't think WADL support in 2.2.3 will be perfect but
> we'll
>> try our best to polish it in 2.3.
>> I also do believe there's a practical advantage in us eventually
>> supporting WSDL2 in some form (meaning the typed server code
> generation at
>> least which is something we can't do with WADL, as well as supporting
>> those users who are working with proxy-based client api) but I can't
>> confirm at this stage when exactly we will do WSDL2. 
>> 
>> WADL instances for RESTful endpoints are available from {base
endpoint
>> address}/services, in addition to SOAP endpoints if any.
>> Note that you can override the location at which listings are
provided
> (in
>> case you'd like '/services' be available to your resources) using
>> 'service-list-path'  parameter, ex :
>> 'service-list-path' = '/listings'
>> 
>> So please give it a try and let us know what you think
>> 
>> thanks, Sergey
>> 
>> 
> 
> -- 
> View this message in context:
>
http://old.nabble.com/JAX-RS-%3A-initial-WADL-support-tp24394736p2674619
> 6.html
> Sent from the cxf-user mailing list archive at Nabble.com.
> 
> 
> 

-- 
View this message in context:
http://old.nabble.com/JAX-RS-%3A-initial-WADL-support-tp24394736p2674667
2.html
Sent from the cxf-user mailing list archive at Nabble.com.