I don't see any point in continuing this ping-pong :-)
Either do "execute" or find a better tool which can handle WADLs
Path("") is really something JAXRS does not talk about - it is
equivalent to having no @Path at all. CXF replaces it internally with
"/". "/" is a minimal value a root path resource must have, showing
<resources base="http://localhost:8085/services/v1/rest/Foo";><resource
path=""><resource path="/execute">
would not make sense at all so the WADLGenerator would need to do some
silly tricks to collapse "" and "/execute" and thus losing the
information about the actual hierarchy
-----Original Message-----
From: vickatvuuch [mailto:[email protected]]
Sent: 11 December 2009 16:54
To: [email protected]
Subject: RE: JAX-RS : initial WADL support
Not really, remember I have an empty @Path("") at the impl level
The bug I think in the <resource path="/"> that is in the middle, which
should have been, according to my annotation - an empty one!
Sergey Beryozkin-2 wrote:
>
> So this is exactly reflects the way you've annotated your resource
class
>
>> http://localhost:8085/services/v1/rest/Foo
>
> Is indeed the base
>
>> resource path="/"
>
> This is your root resource class
>
>> <resource path="/execute">
>
> And this is your resource method
>
> Note that it is kind of immaterial from the client's point of view
what
> "/" and "/execute" are mapped to or how a request like
> http://localhost:8085/services/v1/rest/Foo/execute is handled.
>
> As I said this is a bug in SoapUI in that it can not concatenate
>
> http://localhost:8085/services/v1/rest/Foo, /, /execute
>
> so you need to help it by using "execute"
>
> -----Original Message-----
> From: vickatvuuch [mailto:[email protected]]
> Sent: 11 December 2009 16:41
> To: [email protected]
> Subject: RE: JAX-RS : initial WADL support
>
>
> 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-tp24394736p2674752
> 1.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-tp24394736p2674776
7.html
Sent from the cxf-user mailing list archive at Nabble.com.
