@Path("execute") at the Impl elevel makes it not possible to have other methods..
Can I patch it somehow? Is it possible to replace default WADLGenerator with my custom version? 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.. 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:vlisov...@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-tp24394736p26746672.html Sent from the cxf-user mailing list archive at Nabble.com.