Here is why I had to do it this way.. Use case:
I have have several services grouped under one jaxrs server, with address
such as: /v1/rest
then those services have a root path on the impl such as @Path("/Foo") and
everything is fine.
The other one is a special kind, where I needed a custom out interceptor,
writing
xml to the wire AS-IS, (aka smart servlet case with Xml being the output of
a groovy script),
that forced me to take it out of the main jaxrs server and into its own
jaxrs server,
which is how I eneded up with a server having root such as: /v1/rest/Foo,
leaving the port impl
itself with an empty path @Path("")
Sergey Beryozkin-2 wrote:
>
> Thanks a lot for your feedback and for being patient with me trying to
> convince you "execute" will do the trick :-).
> In fact, I do not think now the problem is with either "execute" or
> "/execute". Rather it is an edge case to do with an empty root @Path
> value.
> If it were possible for you to push "/Foo" from jaxrs:endpoint/@address
> into the root @Path then SoapUI would do well, given it simply
> concatenates multiple values without worrying about the duplicates...
>
> But I'll need to clarify few bits anyway
>
> Thanks, Sergey
>
> -----Original Message-----
> From: vickatvuuch [mailto:[email protected]]
> Sent: 11 December 2009 20:02
> To: [email protected]
> Subject: RE: JAX-RS : initial WADL support
>
>
> 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-tp24394736p2675066
> 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-tp24394736p26751458.html
Sent from the cxf-user mailing list archive at Nabble.com.
