Now I will abuse it a bit and reply with
thanks a lot for your help!
Sergey Beryozkin-2 wrote:
>
> I can accept that I mislead you, sorry :-) But I'm not sure it is a bug.
> For example, you may have
>
> @Path("execute")
>
> and
>
> @Path("/execute")
>
> on two different methods but I do not see the WADL spec [1] requiring
> the implementers to have "execute" in both cases. Thus a consumer should
> be capable of handling both forms. I think the generated WADL is correct
> but I will ask for some clarifications on the WADL list and get back to
> you.
>
> Perhaps if we have a non-empty Path value than it should be used as is
> by WADLGenerator, without '/' being appended. I'm still not sure about
> it but I'll ask...
>
> Also I'll make sure it will be possible to plugin custom generators
>
> Thanks, Sergey
>
> [1] http://www.w3.org/Submission/wadl/
>
>
>
> -----Original Message-----
> From: vickatvuuch [mailto:[email protected]]
> Sent: 11 December 2009 18:01
> To: [email protected]
> Subject: RE: JAX-RS : initial WADL support
>
>
> just tested it out - even when I don't have slash in front of "execute"
> the WADL still has a slash, would you agree that is a bug?
>
> @Path("")
>
> @POST
> @Path("execute")
>
> Produced WADL with resource as follows:
> <resources
> base="http://localhost:8085/services/v1/rest/Scripto";><resource
> path="/"><resource path="/execute">
>
>
> Sergey Beryozkin-2 wrote:
>>
>> 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.
>>
>>
>>
>
> --
> View this message in context:
> http://old.nabble.com/JAX-RS-%3A-initial-WADL-support-tp24394736p2674879
> 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-tp24394736p26750667.html
Sent from the cxf-user mailing list archive at Nabble.com.
