Here is what I see inside the WADL xml:
<resources base="http://localhost:8085/services/v1/rest/Foo";><resource
path="/"><resource path="/execute">
Sergey Beryozkin-2 wrote:
>
> Actually
>
>>> 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
>
> Where exactly do you see this URI ? I recall someone actually posted a
> similar query, possibly on this thread earlier on. It actually looks
> like a bug in SoapUI in that it can not concatenate various path
> fragments properly. For example, CXF JAXRS proxy-based client api will
> produce a correct URI irrespectively of whether a forward slash is
> present or not because it relies on JAXRS UriBuilder.
>
> Cheers, Sergey
>
>>>
>>> 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.
>>
>>
>>
>
> --
> View this message in context:
> http://old.nabble.com/JAX-RS-%3A-initial-WADL-support-tp24394736p2674710
> 8.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-tp24394736p26747521.html
Sent from the cxf-user mailing list archive at Nabble.com.
