You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Sergey Beryozkin <sb...@progress.com> on 2009/07/08 18:23:25 UTC
JAX-RS : initial WADL support
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
RE: JAX-RS : initial WADL support
Posted by vickatvuuch <vl...@gmail.com>.
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:vlisovsky@gmail.com]
> Sent: 11 December 2009 20:02
> To: users@cxf.apache.org
> 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:vlisovsky@gmail.com]
>> Sent: 11 December 2009 18:01
>> To: users@cxf.apache.org
>> 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:vlisovsky@gmail.com]
>>> Sent: 11 December 2009 16:54
>>> To: users@cxf.apache.org
>>> 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:vlisovsky@gmail.com]
>>>> Sent: 11 December 2009 16:41
>>>> To: users@cxf.apache.org
>>>> 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.
RE: JAX-RS : initial WADL support
Posted by Sergey Beryozkin <sb...@progress.com>.
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:vlisovsky@gmail.com]
Sent: 11 December 2009 20:02
To: users@cxf.apache.org
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:vlisovsky@gmail.com]
> Sent: 11 December 2009 18:01
> To: users@cxf.apache.org
> 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:vlisovsky@gmail.com]
>> Sent: 11 December 2009 16:54
>> To: users@cxf.apache.org
>> 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:vlisovsky@gmail.com]
>>> Sent: 11 December 2009 16:41
>>> To: users@cxf.apache.org
>>> 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.
RE: JAX-RS : initial WADL support
Posted by vickatvuuch <vl...@gmail.com>.
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:vlisovsky@gmail.com]
> Sent: 11 December 2009 18:01
> To: users@cxf.apache.org
> 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:vlisovsky@gmail.com]
>> Sent: 11 December 2009 16:54
>> To: users@cxf.apache.org
>> 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:vlisovsky@gmail.com]
>>> Sent: 11 December 2009 16:41
>>> To: users@cxf.apache.org
>>> 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.
RE: JAX-RS : initial WADL support
Posted by Sergey Beryozkin <sb...@progress.com>.
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:vlisovsky@gmail.com]
Sent: 11 December 2009 18:01
To: users@cxf.apache.org
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:vlisovsky@gmail.com]
> Sent: 11 December 2009 16:54
> To: users@cxf.apache.org
> 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:vlisovsky@gmail.com]
>> Sent: 11 December 2009 16:41
>> To: users@cxf.apache.org
>> 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.
RE: JAX-RS : initial WADL support
Posted by vickatvuuch <vl...@gmail.com>.
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:vlisovsky@gmail.com]
> Sent: 11 December 2009 16:54
> To: users@cxf.apache.org
> 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:vlisovsky@gmail.com]
>> Sent: 11 December 2009 16:41
>> To: users@cxf.apache.org
>> 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-tp24394736p26748791.html
Sent from the cxf-user mailing list archive at Nabble.com.
RE: JAX-RS : initial WADL support
Posted by Sergey Beryozkin <sb...@progress.com>.
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:vlisovsky@gmail.com]
Sent: 11 December 2009 16:54
To: users@cxf.apache.org
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:vlisovsky@gmail.com]
> Sent: 11 December 2009 16:41
> To: users@cxf.apache.org
> 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.
RE: JAX-RS : initial WADL support
Posted by vickatvuuch <vl...@gmail.com>.
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:vlisovsky@gmail.com]
> Sent: 11 December 2009 16:41
> To: users@cxf.apache.org
> 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-tp24394736p26747767.html
Sent from the cxf-user mailing list archive at Nabble.com.
RE: JAX-RS : initial WADL support
Posted by Sergey Beryozkin <sb...@progress.com>.
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:vlisovsky@gmail.com]
Sent: 11 December 2009 16:41
To: users@cxf.apache.org
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.
RE: JAX-RS : initial WADL support
Posted by vickatvuuch <vl...@gmail.com>.
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.
RE: JAX-RS : initial WADL support
Posted by Sergey Beryozkin <sb...@progress.com>.
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.
RE: JAX-RS : initial WADL support
Posted by vickatvuuch <vl...@gmail.com>.
ok, I guess I misundrstood you, you meant to put @Path("execute") on the
method itself
without the slash in front of it? I think I tried that also.
I will re-try that again, only concern there is that once you fix it in the
WADLGenerator
my service will stop working without that slash isn't it?
Sergey Beryozkin-2 wrote:
>
>
>
> @Path("execute") at the Impl elevel makes it not possible to have other
> methods..
>
>> S.B : why ? the forward slash should not make a difference at all, as
> far as the selection algorithm is concerned ? Calrify please
>
>
>
>
> 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:vlisovsky@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-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-tp24394736p26747108.html
Sent from the cxf-user mailing list archive at Nabble.com.
Query parameter in WADL is missing a dot ( Was : JAX-RS : initial WADL support)
Posted by Sergey Beryozkin <sb...@progress.com>.
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..
S.B I did a quick test with a method containing
@QueryParam("principal.user") and the generated WADL had a proper value.
Perhaps SoapUI is missing it ?
However, having
QueryParam("") QueryBean, where QueryBean is declared like this :
public static class QueryBean {
private int a;
private int b;
private QueryBean2 bean;
public int getA() {
return a;
}
public int getB() {
return b;
}
public QueryBean2 getC() {
return bean;
}
public void setC(QueryBean2 c) {
bean = c;
}
}
public static class QueryBean2 {
private int a;
private int b;
private QueryBean3 bean;
public int getA() {
return a;
}
public int getB() {
return b;
}
public QueryBean3 getD() {
return bean;
}
public void setD(QueryBean3 d) {
bean = d;
}
}
public static class QueryBean3 {
private int a;
private int b;
public int getA() {
return a;
}
public int getB() {
return b;
}
}
reproduced the issue, 6 query parameters were generated, with the names
of the parent beans being missed. It is fixed on mainline now. So you'll
get
<param name="a" style="query" type="xs:int"/>
<param name="b" style="query" type="xs:int"/>
<param name="c.a" style="query" type="xs:int"/>
<param name="c.b" style="query" type="xs:int"/>
<param name="c.d.a" style="query" type="xs:int"/>
<param name="c.d.b" style="query" type="xs:int"/>
Cheers, Sergey
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:vlisovsky@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-tp24394736p2674667
2.html
Sent from the cxf-user mailing list archive at Nabble.com.
RE: JAX-RS : initial WADL support
Posted by Sergey Beryozkin <sb...@progress.com>.
@Path("execute") at the Impl elevel makes it not possible to have other
methods..
> S.B : why ? the forward slash should not make a difference at all, as
far as the selection algorithm is concerned ? Calrify please
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:vlisovsky@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-tp24394736p2674667
2.html
Sent from the cxf-user mailing list archive at Nabble.com.
RE: JAX-RS : initial WADL support
Posted by vickatvuuch <vl...@gmail.com>.
@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:vlisovsky@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.
RE: JAX-RS : initial WADL support
Posted by Sergey Beryozkin <sb...@progress.com>.
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:vlisovsky@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.
Re: JAX-RS : initial WADL support
Posted by vickatvuuch <vl...@gmail.com>.
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-tp24394736p26746196.html
Sent from the cxf-user mailing list archive at Nabble.com.
RE: JAX-RS : initial WADL support
Posted by Sergey Beryozkin <se...@iona.com>.
Hi Sadhana
I've got it fixed. I've also introduced a property called
'ignore.response.writers' (JAXRSUtils.IGNORE_RESPONSE_WRITERS) which custom
RequestHandler or ResponseHandler filters may want to use to avoid their
Response entities being handled by writers and being directly written to the
stream...
Another option is to write to HttpServletResponse but I thought having this
property would simplify things a bit when needed
cheers, Sergey
Sadhana Jain wrote:
>
> Hi Sergey,
>
> Thanks for the WADL generation support in CXF JAX-RS implementation.
> I tried it and it looks good. I was wondering why the WADL is generated
> within <String>...</String> elements? Is there a way to not get these and
> get only the valid WADL?
>
> Thanks,
> Sadhana
>
> Sadhana Jain
> Sr. Software Engineer
>
>
> Rovi Corporation
> 795 Folsom St, Suite 200
> San Francisco, CA 94107
> Direct: 415.247.5023 | Mobile: 925.212.6495
> sadhana.jain@rovicorp.com
> rovicorp.com
>
>
> Rovi. The new name for Macrovision.
>
>
> -----Original Message-----
> From: Sergey Beryozkin [mailto:sberyozk@progress.com]
> Sent: Wednesday, July 08, 2009 9:23 AM
> To: users@cxf.apache.org
> Subject: JAX-RS : initial WADL support
>
> 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://www.nabble.com/JAX-RS-%3A-initial-WADL-support-tp24394736p25192085.html
Sent from the cxf-user mailing list archive at Nabble.com.
RE: JAX-RS : initial WADL support
Posted by Sergey Beryozkin <se...@iona.com>.
Hi Sadhana
Ok, it's actually a bug in CXF then. Custom MessageBodyWriter should not be
invoked after WADL has been generated - I'll fix it
thanks, Sergey
Sadhana Jain wrote:
>
>
>
> Hi Sergey/Gabo,
>
> Thanks for the replies. Our application is using our own MessageBodyWriter
> (that uses XStream provider instead of JAXB) and it seems that is putting
> the <String> around the WADL xml. I will try to fix this in our
> MessageBodyWriter and hopefully will solve the issue.
>
> Your replies were helpful in debugging the issue so thanks a lot again.
>
> -Sadhana
>
> -----Original Message-----
> From: Sergey Beryozkin [mailto:sergey.beryozkin@iona.com]
> Sent: Wednesday, August 26, 2009 3:38 AM
> To: users@cxf.apache.org
> Subject: Re: JAX-RS : initial WADL support
>
>
> Hi
>
> I missed this query, sorry.
> Just yesterday, I saw a generated WADL embedded in <String/>, in a
> specific
> DOSGi case (when no OSGI HttpService was used). Otherwise it's properly
> presented as XML....
>
> Sadhana, can you help me please in reproducing this issue ? Are you using
> (D)OSGI by any chance ? If not then how exactly your application has been
> set up ?
>
> thanks, Sergey
>
>
> Gabo Manuel wrote:
>>
>> Hi Sadhana,
>>
>> Any chance that an out interceptor is enclosing the result? I think the
>> generation of wadl is still treated as a regular transaction so all in
>> and out interceptor chains apply.
>>
>> Gabo
>>
>> Sadhana Jain wrote:
>>> Hi Sergey,
>>>
>>> Thanks for the WADL generation support in CXF JAX-RS implementation.
>>> I tried it and it looks good. I was wondering why the WADL is generated
>>> within <String>...</String> elements? Is there a way to not get these
>>> and
>>> get only the valid WADL?
>>>
>>> Thanks,
>>> Sadhana
>>>
>>> Sadhana Jain
>>> Sr. Software Engineer
>>>
>>>
>>> Rovi Corporation
>>> 795 Folsom St, Suite 200
>>> San Francisco, CA 94107
>>> Direct: 415.247.5023 | Mobile: 925.212.6495
>>> sadhana.jain@rovicorp.com
>>> rovicorp.com
>>>
>>>
>>> Rovi. The new name for Macrovision.
>>>
>>>
>>> -----Original Message-----
>>> From: Sergey Beryozkin [mailto:sberyozk@progress.com]
>>> Sent: Wednesday, July 08, 2009 9:23 AM
>>> To: users@cxf.apache.org
>>> Subject: JAX-RS : initial WADL support
>>>
>>> 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
>>> ------------------------------------------------------------------------
>>>
>>>
>>> No virus found in this incoming message.
>>> Checked by AVG - www.avg.com
>>> Version: 8.5.409 / Virus Database: 270.13.66/2325 - Release Date:
>>> 08/25/09 06:08:00
>>>
>>>
>>
>>
>
> --
> View this message in context:
> http://www.nabble.com/JAX-RS-%3A-initial-WADL-support-tp24394736p25150356.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
>
>
--
View this message in context: http://www.nabble.com/JAX-RS-%3A-initial-WADL-support-tp24394736p25167268.html
Sent from the cxf-user mailing list archive at Nabble.com.
RE: JAX-RS : initial WADL support
Posted by Sadhana Jain <Sa...@rovicorp.com>.
Hi Sergey/Gabo,
Thanks for the replies. Our application is using our own MessageBodyWriter (that uses XStream provider instead of JAXB) and it seems that is putting the <String> around the WADL xml. I will try to fix this in our MessageBodyWriter and hopefully will solve the issue.
Your replies were helpful in debugging the issue so thanks a lot again.
-Sadhana
-----Original Message-----
From: Sergey Beryozkin [mailto:sergey.beryozkin@iona.com]
Sent: Wednesday, August 26, 2009 3:38 AM
To: users@cxf.apache.org
Subject: Re: JAX-RS : initial WADL support
Hi
I missed this query, sorry.
Just yesterday, I saw a generated WADL embedded in <String/>, in a specific
DOSGi case (when no OSGI HttpService was used). Otherwise it's properly
presented as XML....
Sadhana, can you help me please in reproducing this issue ? Are you using
(D)OSGI by any chance ? If not then how exactly your application has been
set up ?
thanks, Sergey
Gabo Manuel wrote:
>
> Hi Sadhana,
>
> Any chance that an out interceptor is enclosing the result? I think the
> generation of wadl is still treated as a regular transaction so all in
> and out interceptor chains apply.
>
> Gabo
>
> Sadhana Jain wrote:
>> Hi Sergey,
>>
>> Thanks for the WADL generation support in CXF JAX-RS implementation.
>> I tried it and it looks good. I was wondering why the WADL is generated
>> within <String>...</String> elements? Is there a way to not get these and
>> get only the valid WADL?
>>
>> Thanks,
>> Sadhana
>>
>> Sadhana Jain
>> Sr. Software Engineer
>>
>>
>> Rovi Corporation
>> 795 Folsom St, Suite 200
>> San Francisco, CA 94107
>> Direct: 415.247.5023 | Mobile: 925.212.6495
>> sadhana.jain@rovicorp.com
>> rovicorp.com
>>
>>
>> Rovi. The new name for Macrovision.
>>
>>
>> -----Original Message-----
>> From: Sergey Beryozkin [mailto:sberyozk@progress.com]
>> Sent: Wednesday, July 08, 2009 9:23 AM
>> To: users@cxf.apache.org
>> Subject: JAX-RS : initial WADL support
>>
>> 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
>> ------------------------------------------------------------------------
>>
>>
>> No virus found in this incoming message.
>> Checked by AVG - www.avg.com
>> Version: 8.5.409 / Virus Database: 270.13.66/2325 - Release Date:
>> 08/25/09 06:08:00
>>
>>
>
>
--
View this message in context: http://www.nabble.com/JAX-RS-%3A-initial-WADL-support-tp24394736p25150356.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: JAX-RS : initial WADL support
Posted by Sergey Beryozkin <se...@iona.com>.
Hi
I missed this query, sorry.
Just yesterday, I saw a generated WADL embedded in <String/>, in a specific
DOSGi case (when no OSGI HttpService was used). Otherwise it's properly
presented as XML....
Sadhana, can you help me please in reproducing this issue ? Are you using
(D)OSGI by any chance ? If not then how exactly your application has been
set up ?
thanks, Sergey
Gabo Manuel wrote:
>
> Hi Sadhana,
>
> Any chance that an out interceptor is enclosing the result? I think the
> generation of wadl is still treated as a regular transaction so all in
> and out interceptor chains apply.
>
> Gabo
>
> Sadhana Jain wrote:
>> Hi Sergey,
>>
>> Thanks for the WADL generation support in CXF JAX-RS implementation.
>> I tried it and it looks good. I was wondering why the WADL is generated
>> within <String>...</String> elements? Is there a way to not get these and
>> get only the valid WADL?
>>
>> Thanks,
>> Sadhana
>>
>> Sadhana Jain
>> Sr. Software Engineer
>>
>>
>> Rovi Corporation
>> 795 Folsom St, Suite 200
>> San Francisco, CA 94107
>> Direct: 415.247.5023 | Mobile: 925.212.6495
>> sadhana.jain@rovicorp.com
>> rovicorp.com
>>
>>
>> Rovi. The new name for Macrovision.
>>
>>
>> -----Original Message-----
>> From: Sergey Beryozkin [mailto:sberyozk@progress.com]
>> Sent: Wednesday, July 08, 2009 9:23 AM
>> To: users@cxf.apache.org
>> Subject: JAX-RS : initial WADL support
>>
>> 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
>> ------------------------------------------------------------------------
>>
>>
>> No virus found in this incoming message.
>> Checked by AVG - www.avg.com
>> Version: 8.5.409 / Virus Database: 270.13.66/2325 - Release Date:
>> 08/25/09 06:08:00
>>
>>
>
>
--
View this message in context: http://www.nabble.com/JAX-RS-%3A-initial-WADL-support-tp24394736p25150356.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: JAX-RS : initial WADL support
Posted by Gabo Manuel <km...@solegysystems.com>.
Hi Sergey,
I just want to say that the service list page looks great! And the wadl
display in firefox is perfect. Kudos!!
Gabo
Gabo Manuel wrote:
> Hi Sergey,
>
> I sent one directly to your iona address.
>
> Also, I'll take note of that. Good thing you mentioned that. It would
> have driven me nuts trying to figure that out later on.
>
> Again, thanks.
>
> Gabo
>
> Sergey Beryozkin wrote:
>> Hi Gabo
>>
>> Please send me a copy...
>>
>> Unfortunately it is not possible to have multiple root resource
>> classes with
>> the same Path value. Actually, it is possible, but JAX-RS specs says
>> that
>> after the first root class has been selected it is this resource only
>> that
>> the runtime continues working with, others are not checked.
>> We've discussed a couple of times the idea of extending the
>> implementation
>> such that if the first matching resource has no matching operation
>> then then
>> next matching one, if any, is tried next.
>> cheers, Sergey
>>
>> Gabo Manuel wrote:
>>
>>> Hi Sergey,
>>>
>>> Sergey Beryozkin wrote:
>>>
>>>> I'm not sure we can do it at the XML level, XML Parsers used by
>>>> Firefox/IE would just most likely
>>>> skip it as the ignorable whitespaces. HTML WADL view will also be
>>>> done/available later on and it will make the whole WADL instance more
>>>> readable, I was thinking to utilize Mark Nottingham's stylesheet
>>>> but then
>>>> I looked at it again and decided to step back and may be come up with
>>>> something CXF-specific.
>>>>
>>> I was viewing it via notepad++. I'll send you a copy directly.
>>>
>>>
>>>> Now, about 2.
>>>>
>>>> I've been surprised recently to find out root resources with no
>>>> root Path
>>>> annotations can be matched, I think in this case CXF just assumes it's
>>>> @Path("/"). So in your case you have 2 root resource classes, one
>>>> with @Path("/") and
>>>> one with @Path("/Service").
>>>> When you do
>>> I haven't done it yet, but I am seriously planning to. But is it
>>> possible to have two classes to have the same path annotation? I am
>>> thinking of having two services with no path annotations (which as
>>> you said defaults to "/")
>>>
>>>
>>>> /Service/?_wadl
>>>>
>>>> the one with @Path("/Service") will be selected as per the JAX-RS
>>>> selection algorithm. And the WADL generator operates with this class
>>>> only...
>>>>
>>> I was thinking the "/Service/operation" of class2 should also be
>>> included since the path would still match and this would be similar
>>> to the result of actually invoking the said service.
>>>
>>> Gabo
>>>
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>> No virus found in this incoming message.
>> Checked by AVG - www.avg.com Version: 8.5.392 / Virus Database:
>> 270.13.45/2287 - Release Date: 08/07/09 06:22:00
>>
>>
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.392 / Virus Database: 270.13.49/2293 - Release Date: 08/09/09 18:10:00
>
>
Re: JAX-RS : initial WADL support
Posted by Gabo Manuel <km...@solegysystems.com>.
Hi Sergey,
I sent one directly to your iona address.
Also, I'll take note of that. Good thing you mentioned that. It would
have driven me nuts trying to figure that out later on.
Again, thanks.
Gabo
Sergey Beryozkin wrote:
> Hi Gabo
>
> Please send me a copy...
>
> Unfortunately it is not possible to have multiple root resource classes with
> the same Path value. Actually, it is possible, but JAX-RS specs says that
> after the first root class has been selected it is this resource only that
> the runtime continues working with, others are not checked.
> We've discussed a couple of times the idea of extending the implementation
> such that if the first matching resource has no matching operation then then
> next matching one, if any, is tried next.
>
> cheers, Sergey
>
>
> Gabo Manuel wrote:
>
>> Hi Sergey,
>>
>> Sergey Beryozkin wrote:
>>
>>> I'm not sure we can do it at the XML level, XML Parsers used by
>>> Firefox/IE would just most likely
>>> skip it as the ignorable whitespaces. HTML WADL view will also be
>>> done/available later on and it will make the whole WADL instance more
>>> readable, I was thinking to utilize Mark Nottingham's stylesheet but then
>>> I looked at it again and decided to step back and may be come up with
>>> something CXF-specific.
>>>
>>>
>> I was viewing it via notepad++. I'll send you a copy directly.
>>
>>
>>> Now, about 2.
>>>
>>> I've been surprised recently to find out root resources with no root Path
>>> annotations can be matched, I think in this case CXF just assumes it's
>>> @Path("/").
>>> So in your case you have 2 root resource classes, one with @Path("/") and
>>> one with @Path("/Service").
>>> When you do
>>>
>>>
>> I haven't done it yet, but I am seriously planning to. But is it
>> possible to have two classes to have the same path annotation? I am
>> thinking of having two services with no path annotations (which as you
>> said defaults to "/")
>>
>>
>>> /Service/?_wadl
>>>
>>> the one with @Path("/Service") will be selected as per the JAX-RS
>>> selection algorithm. And the WADL generator operates with this class
>>> only...
>>>
>>>
>> I was thinking the "/Service/operation" of class2 should also be
>> included since the path would still match and this would be similar to
>> the result of actually invoking the said service.
>>
>> Gabo
>>
>>
>>
>
>
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.392 / Virus Database: 270.13.45/2287 - Release Date: 08/07/09 06:22:00
>
>
Re: JAX-RS : initial WADL support
Posted by Sergey Beryozkin <se...@iona.com>.
Hi Gabo
Please send me a copy...
Unfortunately it is not possible to have multiple root resource classes with
the same Path value. Actually, it is possible, but JAX-RS specs says that
after the first root class has been selected it is this resource only that
the runtime continues working with, others are not checked.
We've discussed a couple of times the idea of extending the implementation
such that if the first matching resource has no matching operation then then
next matching one, if any, is tried next.
cheers, Sergey
Gabo Manuel wrote:
>
> Hi Sergey,
>
> Sergey Beryozkin wrote:
>> I'm not sure we can do it at the XML level, XML Parsers used by
>> Firefox/IE would just most likely
>> skip it as the ignorable whitespaces. HTML WADL view will also be
>> done/available later on and it will make the whole WADL instance more
>> readable, I was thinking to utilize Mark Nottingham's stylesheet but then
>> I looked at it again and decided to step back and may be come up with
>> something CXF-specific.
>>
> I was viewing it via notepad++. I'll send you a copy directly.
>
>> Now, about 2.
>>
>> I've been surprised recently to find out root resources with no root Path
>> annotations can be matched, I think in this case CXF just assumes it's
>> @Path("/").
>> So in your case you have 2 root resource classes, one with @Path("/") and
>> one with @Path("/Service").
>> When you do
>>
> I haven't done it yet, but I am seriously planning to. But is it
> possible to have two classes to have the same path annotation? I am
> thinking of having two services with no path annotations (which as you
> said defaults to "/")
>
>> /Service/?_wadl
>>
>> the one with @Path("/Service") will be selected as per the JAX-RS
>> selection algorithm. And the WADL generator operates with this class
>> only...
>>
> I was thinking the "/Service/operation" of class2 should also be
> included since the path would still match and this would be similar to
> the result of actually invoking the said service.
>
> Gabo
>
>
--
View this message in context: http://www.nabble.com/JAX-RS-%3A-initial-WADL-support-tp24394736p24863792.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: JAX-RS : initial WADL support
Posted by Sergey Beryozkin <se...@iona.com>.
Hi Gabo -
should not be, we don't have a processor yet but I'm presuming that a
schemas cache will be created after a <grammars/> section has been
processed, with schemas keyed by namespaces, so eventually other prefixes
like 'prefix1' will be bound to corresponding schemas.
cheers, Sergey
Gabo Manuel wrote:
>
> Hi Sergey,
>
> Just want to confirm. It would not be a problem even if they use
> different prefix as long as it evaluates the same, ryt?
>
> Gabo
>
> Sergey Beryozkin wrote:
>> Hi Gabo
>>
>> Agreed about 1.
>> About 2 : the schema is generated by JAXB so WADLGenerator is not
>> controlling the prefixes on the schema itself. 'tns' is typically used by
>> convention. I can't use 'tns' on the top-level wadl:application though
>> because it won't work in cases when multiple schemas have been generated,
>> and it will be a bit confusing in cases when WADL instances are not using
>> default namespaces, because 'tns' would actually link to some other
>> non-WADL
>> namespace.
>> WADL processors should have no problems in processing 'prefix1'/prefix2',
>> etc, 'tns' won't be even visible to them....
>>
>> cheers, Sergey
>>
>>
>> Gabo Manuel wrote:
>>
>>> Hi Sergey,
>>>
>>> A few things:
>>>
>>> 1. I have both XmlRootElement and XmlType annotations in my object. I
>>> added namespace to both of them. By 2.2.4, I'll remove them both.
>>> Currently still using the 2.2.3 release.
>>>
>>> 2. The wadl generated has xmlns:tns and xmlns:prefix1 defined as
>>> "http://domains.some", with tns being used in the grammars, while
>>> prefix1 is being used in the resources. Although, it would still
>>> evaluate the same, I think it would be better to remove the duplicate
>>> and just use the same namespace definition for both grammar and
>>> resource, right?
>>>
>>> Thanks
>>>
>>> Gabo
>>>
>>> Sergey Beryozkin wrote:
>>>
>>>> Hi Gabo
>>>>
>>>> I've just got it fixed. WADLgenerator will now introspect
>>>> package-info.java
>>>> in cases when @XmlRootElement has only a local name set and if the
>>>> namespace
>>>> is available then the resulting WADL will correctly link to a generated
>>>> schema element....
>>>>
>>>> thanks for raising this issue
>>>> Sergey
>>>>
>>>>
>>>> Sergey Beryozkin wrote:
>>>>
>>>>
>>>>> Hi Gabo
>>>>>
>>>>> MyObject has @XmlRootElement with only a local name specified. Does
>>>>> package-info.java has a namespace specified too, in addition to the
>>>>> local
>>>>> name ?
>>>>>
>>>>> cheers, Sergey
>>>>>
>>>>>
>>>>> Gabo Manuel wrote:
>>>>>
>>>>>
>>>>>> Hi Sergey,
>>>>>>
>>>>>> I am a bit confused. How do I supply the namespace needed? I thought
>>>>>> the
>>>>>> package-info.java would be enough.
>>>>>>
>>>>>> Yes, for now I would be limiting the consume to just text/xml. The
>>>>>> initial intent was to take advantage of CXF's handling between xml
>>>>>> and
>>>>>> json. But for now, we would be sticking to text/xml.
>>>>>>
>>>>>> Gabo
>>>>>>
>>>>>> Sergey Beryozkin wrote:
>>>>>>
>>>>>>
>>>>>>> Hi Gabo
>>>>>>>
>>>>>>> thanks...
>>>>>>> The reason you only see the '<representation/>' for my MyObject is
>>>>>>> that
>>>>>>> there's no namespace available , so even though the <grammars/>
>>>>>>> section
>>>>>>> has
>>>>>>> the schema embedded there's no way to link to it from the
>>>>>>> <representation/>.
>>>>>>> May be I should have some XML comment generated which will advise to
>>>>>>> check
>>>>>>> the schema (with no namespace) ?
>>>>>>>
>>>>>>> You might also want to update Consumes("*/*") to require a more
>>>>>>> specific
>>>>>>> media type.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> I haven't tried it lately without the providers, but are primitives
>>>>>>>> now
>>>>>>>> supported out of the box?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> They are but only for text/plain. I'll add a task to wrap them in
>>>>>>> some
>>>>>>> tag
>>>>>>> like <response> for xml media types
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Also, is there somewhere to look to be able to use the tool that
>>>>>>>> creates
>>>>>>>> an http-centric client-code from the wadl?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> No, I haven't started working on the code gen tool yet....But it's
>>>>>>> on
>>>>>>> the
>>>>>>> map
>>>>>>>
>>>>>>> cheers, Sergey
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Gabo Manuel wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Hi Sergey,
>>>>>>>>
>>>>>>>> Sorry for the late response. I may have misrepresented the method,
>>>>>>>> it
>>>>>>>> should be as follows:
>>>>>>>>
>>>>>>>> @WebService(name="MyObjectService")
>>>>>>>> @SOAPBinding(use=Use.LITERAL, style=Style.RPC)
>>>>>>>> @Consumes("*/*")
>>>>>>>> @Produces("text/xml")
>>>>>>>> @Path("/MyObjects")
>>>>>>>> public interface MyObjectService{
>>>>>>>> @GET
>>>>>>>> @Path("/")
>>>>>>>> @WebMethod
>>>>>>>> @WebResult(name="myObjectInstance")
>>>>>>>> public MyObject getMyObject(
>>>>>>>> @QueryParam("uniqueIDField")
>>>>>>>> @WebParam(name="uniqueIDField")
>>>>>>>> long uniqueIDField)
>>>>>>>> ;
>>>>>>>>
>>>>>>>> @PUT
>>>>>>>> @Path("/")
>>>>>>>> @WebMethod
>>>>>>>> @WebResult(name="uniqueIDField")
>>>>>>>> public long insertMyObject(
>>>>>>>> @WebParam(name="myObjectInstance")
>>>>>>>> MyObject myObjectInstance,
>>>>>>>> @QueryParam("reason")
>>>>>>>> @WebParam(name="reason")
>>>>>>>> String reason
>>>>>>>> )
>>>>>>>> ;
>>>>>>>> }
>>>>>>>>
>>>>>>>> @WebService(endpointInterface="some.domain.MyObjectService",
>>>>>>>> serviceName="MyObjectService", portName="MyObjectServicePort")
>>>>>>>> public class MyObjectServiceImpl implements MyObjectService{
>>>>>>>> public MyObject getMyObject(long uniqueIDField) throws
>>>>>>>> SolegyContingencyException{
>>>>>>>> return new MyObject();
>>>>>>>> }
>>>>>>>> public long insertMyObject(MyObject myObjectInstance, String
>>>>>>>> reason)
>>>>>>>> throws SolegyContingencyException{
>>>>>>>> return 1;
>>>>>>>> }
>>>>>>>> }
>>>>>>>>
>>>>>>>> @XmlType(name="MyObject")
>>>>>>>> @XmlAccessorType(XmlAccessType.PROPERTY)
>>>>>>>> @XmlRootElement(name="MyObject")
>>>>>>>> public class MyObject {
>>>>>>>> private long uniqueIDField;
>>>>>>>> @GET
>>>>>>>> @Path("/uniqueIDField")
>>>>>>>> public long getUniqueIDField() {
>>>>>>>> return uniqueIDField;
>>>>>>>> }
>>>>>>>> public void setUniqueIDField(long uniqueIDField) {
>>>>>>>> this.uniqueIDField = uniqueIDField;
>>>>>>>> }
>>>>>>>> }
>>>>>>>>
>>>>>>>> The wadl section i get is something as follows:
>>>>>>>>
>>>>>>>> <method name="GET">
>>>>>>>> <request>
>>>>>>>>
>>>>>>>> </request>
>>>>>>>> <response>
>>>>>>>> <representation mediaType="text/xml"/>
>>>>>>>> </response>
>>>>>>>> </method>
>>>>>>>> <method name="PUT">
>>>>>>>> <request>
>>>>>>>> <representation/>
>>>>>>>>
>>>>>>>> </request>
>>>>>>>> <response>
>>>>>>>> <!-- Primitive type : xs:long --><representation
>>>>>>>> mediaType="text/xml"/>
>>>>>>>> </response>
>>>>>>>> </method>
>>>>>>>>
>>>>>>>> And yes, I did specify text/xml. I also have providers included to
>>>>>>>> wrap
>>>>>>>> the response in tags. I had to add the providers because at the
>>>>>>>> time
>>>>>>>> (2.0), primitives were not supported. I haven't tried it lately
>>>>>>>> without
>>>>>>>> the providers, but are primitives now supported out of the box?
>>>>>>>>
>>>>>>>> Also, is there somewhere to look to be able to use the tool that
>>>>>>>> creates
>>>>>>>> an http-centric client-code from the wadl?
>>>>>>>>
>>>>>>>> Thanks!
>>>>>>>>
>>>>>>>> Gabo.
>>>>>>>>
>>>>>>>> Sergey Beryozkin wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Hi Gabo
>>>>>>>>>
>>>>>>>>> It is an 'Object' so a WSDL generator has no idea what else to
>>>>>>>>> say,
>>>>>>>>> apart
>>>>>>>>> from <representation/>. If you add "Consumes' with some values
>>>>>>>>> then
>>>>>>>>> you'll
>>>>>>>>> get a bit more specific tag...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> However, there appears to be a bug :
>>>>>>>>>
>>>>>>>>> <response><!-- Primitive type : xs:long
>>>>>>>>> --><representation
>>>>>>>>> mediaType="text/xml"/></response></method></resource>
>>>>>>>>>
>>>>>>>>> or do you have Produces('text/xml') on the class itself ? Can you
>>>>>>>>> please
>>>>>>>>> send me a class sample so that I can fix it ?
>>>>>>>>>
>>>>>>>>> cheers, Sergey
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------
>>>>>>>
>>>>>>>
>>>>>>> No virus found in this incoming message.
>>>>>>> Checked by AVG - www.avg.com
>>>>>>> Version: 8.5.409 / Virus Database: 270.13.62/2315 - Release Date:
>>>>>>> 08/20/09 06:05:00
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>> No virus found in this incoming message.
>>>> Checked by AVG - www.avg.com
>>>> Version: 8.5.409 / Virus Database: 270.13.65/2323 - Release Date:
>>>> 08/24/09 06:05:00
>>>>
>>>>
>>>>
>>>
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>> No virus found in this incoming message.
>> Checked by AVG - www.avg.com
>> Version: 8.5.339 / Virus Database: 270.13.67/2326 - Release Date:
>> 08/25/09 18:07:00
>>
>>
>
>
--
View this message in context: http://www.nabble.com/JAX-RS-%3A-initial-WADL-support-tp24394736p25167275.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: JAX-RS : initial WADL support
Posted by Gabo Manuel <km...@solegysystems.com>.
Hi Sergey,
Just want to confirm. It would not be a problem even if they use
different prefix as long as it evaluates the same, ryt?
Gabo
Sergey Beryozkin wrote:
> Hi Gabo
>
> Agreed about 1.
> About 2 : the schema is generated by JAXB so WADLGenerator is not
> controlling the prefixes on the schema itself. 'tns' is typically used by
> convention. I can't use 'tns' on the top-level wadl:application though
> because it won't work in cases when multiple schemas have been generated,
> and it will be a bit confusing in cases when WADL instances are not using
> default namespaces, because 'tns' would actually link to some other non-WADL
> namespace.
> WADL processors should have no problems in processing 'prefix1'/prefix2',
> etc, 'tns' won't be even visible to them....
>
> cheers, Sergey
>
>
> Gabo Manuel wrote:
>
>> Hi Sergey,
>>
>> A few things:
>>
>> 1. I have both XmlRootElement and XmlType annotations in my object. I
>> added namespace to both of them. By 2.2.4, I'll remove them both.
>> Currently still using the 2.2.3 release.
>>
>> 2. The wadl generated has xmlns:tns and xmlns:prefix1 defined as
>> "http://domains.some", with tns being used in the grammars, while
>> prefix1 is being used in the resources. Although, it would still
>> evaluate the same, I think it would be better to remove the duplicate
>> and just use the same namespace definition for both grammar and
>> resource, right?
>>
>> Thanks
>>
>> Gabo
>>
>> Sergey Beryozkin wrote:
>>
>>> Hi Gabo
>>>
>>> I've just got it fixed. WADLgenerator will now introspect
>>> package-info.java
>>> in cases when @XmlRootElement has only a local name set and if the
>>> namespace
>>> is available then the resulting WADL will correctly link to a generated
>>> schema element....
>>>
>>> thanks for raising this issue
>>> Sergey
>>>
>>>
>>> Sergey Beryozkin wrote:
>>>
>>>
>>>> Hi Gabo
>>>>
>>>> MyObject has @XmlRootElement with only a local name specified. Does
>>>> package-info.java has a namespace specified too, in addition to the
>>>> local
>>>> name ?
>>>>
>>>> cheers, Sergey
>>>>
>>>>
>>>> Gabo Manuel wrote:
>>>>
>>>>
>>>>> Hi Sergey,
>>>>>
>>>>> I am a bit confused. How do I supply the namespace needed? I thought
>>>>> the
>>>>> package-info.java would be enough.
>>>>>
>>>>> Yes, for now I would be limiting the consume to just text/xml. The
>>>>> initial intent was to take advantage of CXF's handling between xml and
>>>>> json. But for now, we would be sticking to text/xml.
>>>>>
>>>>> Gabo
>>>>>
>>>>> Sergey Beryozkin wrote:
>>>>>
>>>>>
>>>>>> Hi Gabo
>>>>>>
>>>>>> thanks...
>>>>>> The reason you only see the '<representation/>' for my MyObject is
>>>>>> that
>>>>>> there's no namespace available , so even though the <grammars/>
>>>>>> section
>>>>>> has
>>>>>> the schema embedded there's no way to link to it from the
>>>>>> <representation/>.
>>>>>> May be I should have some XML comment generated which will advise to
>>>>>> check
>>>>>> the schema (with no namespace) ?
>>>>>>
>>>>>> You might also want to update Consumes("*/*") to require a more
>>>>>> specific
>>>>>> media type.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> I haven't tried it lately without the providers, but are primitives
>>>>>>> now
>>>>>>> supported out of the box?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> They are but only for text/plain. I'll add a task to wrap them in some
>>>>>> tag
>>>>>> like <response> for xml media types
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Also, is there somewhere to look to be able to use the tool that
>>>>>>> creates
>>>>>>> an http-centric client-code from the wadl?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> No, I haven't started working on the code gen tool yet....But it's on
>>>>>> the
>>>>>> map
>>>>>>
>>>>>> cheers, Sergey
>>>>>>
>>>>>>
>>>>>>
>>>>>> Gabo Manuel wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Hi Sergey,
>>>>>>>
>>>>>>> Sorry for the late response. I may have misrepresented the method, it
>>>>>>> should be as follows:
>>>>>>>
>>>>>>> @WebService(name="MyObjectService")
>>>>>>> @SOAPBinding(use=Use.LITERAL, style=Style.RPC)
>>>>>>> @Consumes("*/*")
>>>>>>> @Produces("text/xml")
>>>>>>> @Path("/MyObjects")
>>>>>>> public interface MyObjectService{
>>>>>>> @GET
>>>>>>> @Path("/")
>>>>>>> @WebMethod
>>>>>>> @WebResult(name="myObjectInstance")
>>>>>>> public MyObject getMyObject(
>>>>>>> @QueryParam("uniqueIDField")
>>>>>>> @WebParam(name="uniqueIDField")
>>>>>>> long uniqueIDField)
>>>>>>> ;
>>>>>>>
>>>>>>> @PUT
>>>>>>> @Path("/")
>>>>>>> @WebMethod
>>>>>>> @WebResult(name="uniqueIDField")
>>>>>>> public long insertMyObject(
>>>>>>> @WebParam(name="myObjectInstance")
>>>>>>> MyObject myObjectInstance,
>>>>>>> @QueryParam("reason")
>>>>>>> @WebParam(name="reason")
>>>>>>> String reason
>>>>>>> )
>>>>>>> ;
>>>>>>> }
>>>>>>>
>>>>>>> @WebService(endpointInterface="some.domain.MyObjectService",
>>>>>>> serviceName="MyObjectService", portName="MyObjectServicePort")
>>>>>>> public class MyObjectServiceImpl implements MyObjectService{
>>>>>>> public MyObject getMyObject(long uniqueIDField) throws
>>>>>>> SolegyContingencyException{
>>>>>>> return new MyObject();
>>>>>>> }
>>>>>>> public long insertMyObject(MyObject myObjectInstance, String
>>>>>>> reason)
>>>>>>> throws SolegyContingencyException{
>>>>>>> return 1;
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>> @XmlType(name="MyObject")
>>>>>>> @XmlAccessorType(XmlAccessType.PROPERTY)
>>>>>>> @XmlRootElement(name="MyObject")
>>>>>>> public class MyObject {
>>>>>>> private long uniqueIDField;
>>>>>>> @GET
>>>>>>> @Path("/uniqueIDField")
>>>>>>> public long getUniqueIDField() {
>>>>>>> return uniqueIDField;
>>>>>>> }
>>>>>>> public void setUniqueIDField(long uniqueIDField) {
>>>>>>> this.uniqueIDField = uniqueIDField;
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>> The wadl section i get is something as follows:
>>>>>>>
>>>>>>> <method name="GET">
>>>>>>> <request>
>>>>>>>
>>>>>>> </request>
>>>>>>> <response>
>>>>>>> <representation mediaType="text/xml"/>
>>>>>>> </response>
>>>>>>> </method>
>>>>>>> <method name="PUT">
>>>>>>> <request>
>>>>>>> <representation/>
>>>>>>>
>>>>>>> </request>
>>>>>>> <response>
>>>>>>> <!-- Primitive type : xs:long --><representation
>>>>>>> mediaType="text/xml"/>
>>>>>>> </response>
>>>>>>> </method>
>>>>>>>
>>>>>>> And yes, I did specify text/xml. I also have providers included to
>>>>>>> wrap
>>>>>>> the response in tags. I had to add the providers because at the time
>>>>>>> (2.0), primitives were not supported. I haven't tried it lately
>>>>>>> without
>>>>>>> the providers, but are primitives now supported out of the box?
>>>>>>>
>>>>>>> Also, is there somewhere to look to be able to use the tool that
>>>>>>> creates
>>>>>>> an http-centric client-code from the wadl?
>>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>> Gabo.
>>>>>>>
>>>>>>> Sergey Beryozkin wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Hi Gabo
>>>>>>>>
>>>>>>>> It is an 'Object' so a WSDL generator has no idea what else to say,
>>>>>>>> apart
>>>>>>>> from <representation/>. If you add "Consumes' with some values then
>>>>>>>> you'll
>>>>>>>> get a bit more specific tag...
>>>>>>>>
>>>>>>>>
>>>>>>>> However, there appears to be a bug :
>>>>>>>>
>>>>>>>> <response><!-- Primitive type : xs:long
>>>>>>>> --><representation
>>>>>>>> mediaType="text/xml"/></response></method></resource>
>>>>>>>>
>>>>>>>> or do you have Produces('text/xml') on the class itself ? Can you
>>>>>>>> please
>>>>>>>> send me a class sample so that I can fix it ?
>>>>>>>>
>>>>>>>> cheers, Sergey
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------
>>>>>>
>>>>>>
>>>>>> No virus found in this incoming message.
>>>>>> Checked by AVG - www.avg.com
>>>>>> Version: 8.5.409 / Virus Database: 270.13.62/2315 - Release Date:
>>>>>> 08/20/09 06:05:00
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>> No virus found in this incoming message.
>>> Checked by AVG - www.avg.com
>>> Version: 8.5.409 / Virus Database: 270.13.65/2323 - Release Date:
>>> 08/24/09 06:05:00
>>>
>>>
>>>
>>
>
>
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.339 / Virus Database: 270.13.67/2326 - Release Date: 08/25/09 18:07:00
>
>
Re: JAX-RS : initial WADL support
Posted by Sergey Beryozkin <se...@iona.com>.
Hi Gabo
Agreed about 1.
About 2 : the schema is generated by JAXB so WADLGenerator is not
controlling the prefixes on the schema itself. 'tns' is typically used by
convention. I can't use 'tns' on the top-level wadl:application though
because it won't work in cases when multiple schemas have been generated,
and it will be a bit confusing in cases when WADL instances are not using
default namespaces, because 'tns' would actually link to some other non-WADL
namespace.
WADL processors should have no problems in processing 'prefix1'/prefix2',
etc, 'tns' won't be even visible to them....
cheers, Sergey
Gabo Manuel wrote:
>
> Hi Sergey,
>
> A few things:
>
> 1. I have both XmlRootElement and XmlType annotations in my object. I
> added namespace to both of them. By 2.2.4, I'll remove them both.
> Currently still using the 2.2.3 release.
>
> 2. The wadl generated has xmlns:tns and xmlns:prefix1 defined as
> "http://domains.some", with tns being used in the grammars, while
> prefix1 is being used in the resources. Although, it would still
> evaluate the same, I think it would be better to remove the duplicate
> and just use the same namespace definition for both grammar and
> resource, right?
>
> Thanks
>
> Gabo
>
> Sergey Beryozkin wrote:
>> Hi Gabo
>>
>> I've just got it fixed. WADLgenerator will now introspect
>> package-info.java
>> in cases when @XmlRootElement has only a local name set and if the
>> namespace
>> is available then the resulting WADL will correctly link to a generated
>> schema element....
>>
>> thanks for raising this issue
>> Sergey
>>
>>
>> Sergey Beryozkin wrote:
>>
>>> Hi Gabo
>>>
>>> MyObject has @XmlRootElement with only a local name specified. Does
>>> package-info.java has a namespace specified too, in addition to the
>>> local
>>> name ?
>>>
>>> cheers, Sergey
>>>
>>>
>>> Gabo Manuel wrote:
>>>
>>>> Hi Sergey,
>>>>
>>>> I am a bit confused. How do I supply the namespace needed? I thought
>>>> the
>>>> package-info.java would be enough.
>>>>
>>>> Yes, for now I would be limiting the consume to just text/xml. The
>>>> initial intent was to take advantage of CXF's handling between xml and
>>>> json. But for now, we would be sticking to text/xml.
>>>>
>>>> Gabo
>>>>
>>>> Sergey Beryozkin wrote:
>>>>
>>>>> Hi Gabo
>>>>>
>>>>> thanks...
>>>>> The reason you only see the '<representation/>' for my MyObject is
>>>>> that
>>>>> there's no namespace available , so even though the <grammars/>
>>>>> section
>>>>> has
>>>>> the schema embedded there's no way to link to it from the
>>>>> <representation/>.
>>>>> May be I should have some XML comment generated which will advise to
>>>>> check
>>>>> the schema (with no namespace) ?
>>>>>
>>>>> You might also want to update Consumes("*/*") to require a more
>>>>> specific
>>>>> media type.
>>>>>
>>>>>
>>>>>
>>>>>> I haven't tried it lately without the providers, but are primitives
>>>>>> now
>>>>>> supported out of the box?
>>>>>>
>>>>>>
>>>>> They are but only for text/plain. I'll add a task to wrap them in some
>>>>> tag
>>>>> like <response> for xml media types
>>>>>
>>>>>
>>>>>
>>>>>> Also, is there somewhere to look to be able to use the tool that
>>>>>> creates
>>>>>> an http-centric client-code from the wadl?
>>>>>>
>>>>>>
>>>>> No, I haven't started working on the code gen tool yet....But it's on
>>>>> the
>>>>> map
>>>>>
>>>>> cheers, Sergey
>>>>>
>>>>>
>>>>>
>>>>> Gabo Manuel wrote:
>>>>>
>>>>>
>>>>>> Hi Sergey,
>>>>>>
>>>>>> Sorry for the late response. I may have misrepresented the method, it
>>>>>> should be as follows:
>>>>>>
>>>>>> @WebService(name="MyObjectService")
>>>>>> @SOAPBinding(use=Use.LITERAL, style=Style.RPC)
>>>>>> @Consumes("*/*")
>>>>>> @Produces("text/xml")
>>>>>> @Path("/MyObjects")
>>>>>> public interface MyObjectService{
>>>>>> @GET
>>>>>> @Path("/")
>>>>>> @WebMethod
>>>>>> @WebResult(name="myObjectInstance")
>>>>>> public MyObject getMyObject(
>>>>>> @QueryParam("uniqueIDField")
>>>>>> @WebParam(name="uniqueIDField")
>>>>>> long uniqueIDField)
>>>>>> ;
>>>>>>
>>>>>> @PUT
>>>>>> @Path("/")
>>>>>> @WebMethod
>>>>>> @WebResult(name="uniqueIDField")
>>>>>> public long insertMyObject(
>>>>>> @WebParam(name="myObjectInstance")
>>>>>> MyObject myObjectInstance,
>>>>>> @QueryParam("reason")
>>>>>> @WebParam(name="reason")
>>>>>> String reason
>>>>>> )
>>>>>> ;
>>>>>> }
>>>>>>
>>>>>> @WebService(endpointInterface="some.domain.MyObjectService",
>>>>>> serviceName="MyObjectService", portName="MyObjectServicePort")
>>>>>> public class MyObjectServiceImpl implements MyObjectService{
>>>>>> public MyObject getMyObject(long uniqueIDField) throws
>>>>>> SolegyContingencyException{
>>>>>> return new MyObject();
>>>>>> }
>>>>>> public long insertMyObject(MyObject myObjectInstance, String
>>>>>> reason)
>>>>>> throws SolegyContingencyException{
>>>>>> return 1;
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> @XmlType(name="MyObject")
>>>>>> @XmlAccessorType(XmlAccessType.PROPERTY)
>>>>>> @XmlRootElement(name="MyObject")
>>>>>> public class MyObject {
>>>>>> private long uniqueIDField;
>>>>>> @GET
>>>>>> @Path("/uniqueIDField")
>>>>>> public long getUniqueIDField() {
>>>>>> return uniqueIDField;
>>>>>> }
>>>>>> public void setUniqueIDField(long uniqueIDField) {
>>>>>> this.uniqueIDField = uniqueIDField;
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> The wadl section i get is something as follows:
>>>>>>
>>>>>> <method name="GET">
>>>>>> <request>
>>>>>>
>>>>>> </request>
>>>>>> <response>
>>>>>> <representation mediaType="text/xml"/>
>>>>>> </response>
>>>>>> </method>
>>>>>> <method name="PUT">
>>>>>> <request>
>>>>>> <representation/>
>>>>>>
>>>>>> </request>
>>>>>> <response>
>>>>>> <!-- Primitive type : xs:long --><representation
>>>>>> mediaType="text/xml"/>
>>>>>> </response>
>>>>>> </method>
>>>>>>
>>>>>> And yes, I did specify text/xml. I also have providers included to
>>>>>> wrap
>>>>>> the response in tags. I had to add the providers because at the time
>>>>>> (2.0), primitives were not supported. I haven't tried it lately
>>>>>> without
>>>>>> the providers, but are primitives now supported out of the box?
>>>>>>
>>>>>> Also, is there somewhere to look to be able to use the tool that
>>>>>> creates
>>>>>> an http-centric client-code from the wadl?
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> Gabo.
>>>>>>
>>>>>> Sergey Beryozkin wrote:
>>>>>>
>>>>>>
>>>>>>> Hi Gabo
>>>>>>>
>>>>>>> It is an 'Object' so a WSDL generator has no idea what else to say,
>>>>>>> apart
>>>>>>> from <representation/>. If you add "Consumes' with some values then
>>>>>>> you'll
>>>>>>> get a bit more specific tag...
>>>>>>>
>>>>>>>
>>>>>>> However, there appears to be a bug :
>>>>>>>
>>>>>>> <response><!-- Primitive type : xs:long
>>>>>>> --><representation
>>>>>>> mediaType="text/xml"/></response></method></resource>
>>>>>>>
>>>>>>> or do you have Produces('text/xml') on the class itself ? Can you
>>>>>>> please
>>>>>>> send me a class sample so that I can fix it ?
>>>>>>>
>>>>>>> cheers, Sergey
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>>
>>>>> No virus found in this incoming message.
>>>>> Checked by AVG - www.avg.com
>>>>> Version: 8.5.409 / Virus Database: 270.13.62/2315 - Release Date:
>>>>> 08/20/09 06:05:00
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>> No virus found in this incoming message.
>> Checked by AVG - www.avg.com
>> Version: 8.5.409 / Virus Database: 270.13.65/2323 - Release Date:
>> 08/24/09 06:05:00
>>
>>
>
>
--
View this message in context: http://www.nabble.com/JAX-RS-%3A-initial-WADL-support-tp24394736p25150491.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: JAX-RS : initial WADL support
Posted by Gabo Manuel <km...@solegysystems.com>.
Hi Sergey,
A few things:
1. I have both XmlRootElement and XmlType annotations in my object. I
added namespace to both of them. By 2.2.4, I'll remove them both.
Currently still using the 2.2.3 release.
2. The wadl generated has xmlns:tns and xmlns:prefix1 defined as
"http://domains.some", with tns being used in the grammars, while
prefix1 is being used in the resources. Although, it would still
evaluate the same, I think it would be better to remove the duplicate
and just use the same namespace definition for both grammar and
resource, right?
Thanks
Gabo
Sergey Beryozkin wrote:
> Hi Gabo
>
> I've just got it fixed. WADLgenerator will now introspect package-info.java
> in cases when @XmlRootElement has only a local name set and if the namespace
> is available then the resulting WADL will correctly link to a generated
> schema element....
>
> thanks for raising this issue
> Sergey
>
>
> Sergey Beryozkin wrote:
>
>> Hi Gabo
>>
>> MyObject has @XmlRootElement with only a local name specified. Does
>> package-info.java has a namespace specified too, in addition to the local
>> name ?
>>
>> cheers, Sergey
>>
>>
>> Gabo Manuel wrote:
>>
>>> Hi Sergey,
>>>
>>> I am a bit confused. How do I supply the namespace needed? I thought the
>>> package-info.java would be enough.
>>>
>>> Yes, for now I would be limiting the consume to just text/xml. The
>>> initial intent was to take advantage of CXF's handling between xml and
>>> json. But for now, we would be sticking to text/xml.
>>>
>>> Gabo
>>>
>>> Sergey Beryozkin wrote:
>>>
>>>> Hi Gabo
>>>>
>>>> thanks...
>>>> The reason you only see the '<representation/>' for my MyObject is that
>>>> there's no namespace available , so even though the <grammars/> section
>>>> has
>>>> the schema embedded there's no way to link to it from the
>>>> <representation/>.
>>>> May be I should have some XML comment generated which will advise to
>>>> check
>>>> the schema (with no namespace) ?
>>>>
>>>> You might also want to update Consumes("*/*") to require a more specific
>>>> media type.
>>>>
>>>>
>>>>
>>>>> I haven't tried it lately without the providers, but are primitives now
>>>>> supported out of the box?
>>>>>
>>>>>
>>>> They are but only for text/plain. I'll add a task to wrap them in some
>>>> tag
>>>> like <response> for xml media types
>>>>
>>>>
>>>>
>>>>> Also, is there somewhere to look to be able to use the tool that
>>>>> creates
>>>>> an http-centric client-code from the wadl?
>>>>>
>>>>>
>>>> No, I haven't started working on the code gen tool yet....But it's on
>>>> the
>>>> map
>>>>
>>>> cheers, Sergey
>>>>
>>>>
>>>>
>>>> Gabo Manuel wrote:
>>>>
>>>>
>>>>> Hi Sergey,
>>>>>
>>>>> Sorry for the late response. I may have misrepresented the method, it
>>>>> should be as follows:
>>>>>
>>>>> @WebService(name="MyObjectService")
>>>>> @SOAPBinding(use=Use.LITERAL, style=Style.RPC)
>>>>> @Consumes("*/*")
>>>>> @Produces("text/xml")
>>>>> @Path("/MyObjects")
>>>>> public interface MyObjectService{
>>>>> @GET
>>>>> @Path("/")
>>>>> @WebMethod
>>>>> @WebResult(name="myObjectInstance")
>>>>> public MyObject getMyObject(
>>>>> @QueryParam("uniqueIDField")
>>>>> @WebParam(name="uniqueIDField")
>>>>> long uniqueIDField)
>>>>> ;
>>>>>
>>>>> @PUT
>>>>> @Path("/")
>>>>> @WebMethod
>>>>> @WebResult(name="uniqueIDField")
>>>>> public long insertMyObject(
>>>>> @WebParam(name="myObjectInstance")
>>>>> MyObject myObjectInstance,
>>>>> @QueryParam("reason")
>>>>> @WebParam(name="reason")
>>>>> String reason
>>>>> )
>>>>> ;
>>>>> }
>>>>>
>>>>> @WebService(endpointInterface="some.domain.MyObjectService",
>>>>> serviceName="MyObjectService", portName="MyObjectServicePort")
>>>>> public class MyObjectServiceImpl implements MyObjectService{
>>>>> public MyObject getMyObject(long uniqueIDField) throws
>>>>> SolegyContingencyException{
>>>>> return new MyObject();
>>>>> }
>>>>> public long insertMyObject(MyObject myObjectInstance, String
>>>>> reason)
>>>>> throws SolegyContingencyException{
>>>>> return 1;
>>>>> }
>>>>> }
>>>>>
>>>>> @XmlType(name="MyObject")
>>>>> @XmlAccessorType(XmlAccessType.PROPERTY)
>>>>> @XmlRootElement(name="MyObject")
>>>>> public class MyObject {
>>>>> private long uniqueIDField;
>>>>> @GET
>>>>> @Path("/uniqueIDField")
>>>>> public long getUniqueIDField() {
>>>>> return uniqueIDField;
>>>>> }
>>>>> public void setUniqueIDField(long uniqueIDField) {
>>>>> this.uniqueIDField = uniqueIDField;
>>>>> }
>>>>> }
>>>>>
>>>>> The wadl section i get is something as follows:
>>>>>
>>>>> <method name="GET">
>>>>> <request>
>>>>>
>>>>> </request>
>>>>> <response>
>>>>> <representation mediaType="text/xml"/>
>>>>> </response>
>>>>> </method>
>>>>> <method name="PUT">
>>>>> <request>
>>>>> <representation/>
>>>>>
>>>>> </request>
>>>>> <response>
>>>>> <!-- Primitive type : xs:long --><representation
>>>>> mediaType="text/xml"/>
>>>>> </response>
>>>>> </method>
>>>>>
>>>>> And yes, I did specify text/xml. I also have providers included to wrap
>>>>> the response in tags. I had to add the providers because at the time
>>>>> (2.0), primitives were not supported. I haven't tried it lately without
>>>>> the providers, but are primitives now supported out of the box?
>>>>>
>>>>> Also, is there somewhere to look to be able to use the tool that
>>>>> creates
>>>>> an http-centric client-code from the wadl?
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Gabo.
>>>>>
>>>>> Sergey Beryozkin wrote:
>>>>>
>>>>>
>>>>>> Hi Gabo
>>>>>>
>>>>>> It is an 'Object' so a WSDL generator has no idea what else to say,
>>>>>> apart
>>>>>> from <representation/>. If you add "Consumes' with some values then
>>>>>> you'll
>>>>>> get a bit more specific tag...
>>>>>>
>>>>>>
>>>>>> However, there appears to be a bug :
>>>>>>
>>>>>> <response><!-- Primitive type : xs:long
>>>>>> --><representation
>>>>>> mediaType="text/xml"/></response></method></resource>
>>>>>>
>>>>>> or do you have Produces('text/xml') on the class itself ? Can you
>>>>>> please
>>>>>> send me a class sample so that I can fix it ?
>>>>>>
>>>>>> cheers, Sergey
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>> No virus found in this incoming message.
>>>> Checked by AVG - www.avg.com
>>>> Version: 8.5.409 / Virus Database: 270.13.62/2315 - Release Date:
>>>> 08/20/09 06:05:00
>>>>
>>>>
>>>>
>>>
>>
>
>
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.409 / Virus Database: 270.13.65/2323 - Release Date: 08/24/09 06:05:00
>
>
Re: JAX-RS : initial WADL support
Posted by John Klassa <jo...@klassa.com>.
Just tried it... That rocks!
On Dec 7, 2009, at 12:04 PM, Sergey Beryozkin wrote:
> Hi, some info can be found here :
>
> http://cwiki.apache.org/CXF20DOC/jax-rs.html#JAX-RS-ServicelistingsandWADLsupport
>
> cheers, Sergey
>
>
> Hi,
>
> How does one auto-generate a WADL from a JAX-RS implementation? Or am I reading this incorrectly?
>
> Thanks!
>
> On Dec 7, 2009, at 7:57 AM, Sergey Beryozkin wrote:
>
>> Hi Gabo
>>
>>> Hi Sergey,
>>> Sorry about that. But you did get the idea tho. :D
>>>> Is it the wadl:request element which has no links to the schema types ? If yes then it is expected when @Consumes is set to */*, given that it may even be that only a non-XML format which is accepted by a method...
>>> Shouldn't the method still show some description of what the method is expecting? Maybe a redundancy of what was described in the grammar.
>>
>> See http://svn.apache.org/repos/asf/cxf/trunk/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/ext/Description.java
>>
>>> I would be trying having multiple specific values and update this thread of the results. Might take a while, got dragged to another task.
>>
>> Having @Consumes with multiple values will result in the generated WADL reflecting it. Same for @Produces.
>>
>> hope it helps, Sergey
>>
>>> Thanks again!
>>> Gabo
>>>>
>>>> cheers, Sergey
>
Re: JAX-RS : initial WADL support
Posted by Sergey Beryozkin <sb...@progress.com>.
Hi, some info can be found here :
http://cwiki.apache.org/CXF20DOC/jax-rs.html#JAX-RS-ServicelistingsandWADLsupport
cheers, Sergey
Hi,
How does one auto-generate a WADL from a JAX-RS implementation? Or am I reading this incorrectly?
Thanks!
On Dec 7, 2009, at 7:57 AM, Sergey Beryozkin wrote:
> Hi Gabo
>
>> Hi Sergey,
>> Sorry about that. But you did get the idea tho. :D
>>> Is it the wadl:request element which has no links to the schema types ? If yes then it is expected when @Consumes is set to */*,
>>> given that it may even be that only a non-XML format which is accepted by a method...
>> Shouldn't the method still show some description of what the method is expecting? Maybe a redundancy of what was described in the
>> grammar.
>
> See http://svn.apache.org/repos/asf/cxf/trunk/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/ext/Description.java
>
>> I would be trying having multiple specific values and update this thread of the results. Might take a while, got dragged to
>> another task.
>
> Having @Consumes with multiple values will result in the generated WADL reflecting it. Same for @Produces.
>
> hope it helps, Sergey
>
>> Thanks again!
>> Gabo
>>>
>>> cheers, Sergey
Re: JAX-RS : initial WADL support
Posted by John Klassa <jo...@klassa.com>.
Hi,
How does one auto-generate a WADL from a JAX-RS implementation? Or am I reading this incorrectly?
Thanks!
On Dec 7, 2009, at 7:57 AM, Sergey Beryozkin wrote:
> Hi Gabo
>
>> Hi Sergey,
>> Sorry about that. But you did get the idea tho. :D
>>> Is it the wadl:request element which has no links to the schema types ? If yes then it is expected when @Consumes is set to */*, given that it may even be that only a non-XML format which is accepted by a method...
>> Shouldn't the method still show some description of what the method is expecting? Maybe a redundancy of what was described in the grammar.
>
> See http://svn.apache.org/repos/asf/cxf/trunk/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/ext/Description.java
>
>> I would be trying having multiple specific values and update this thread of the results. Might take a while, got dragged to another task.
>
> Having @Consumes with multiple values will result in the generated WADL reflecting it. Same for @Produces.
>
> hope it helps, Sergey
>
>> Thanks again!
>> Gabo
>>>
>>> cheers, Sergey
Re: JAX-RS : initial WADL support
Posted by Sergey Beryozkin <sb...@progress.com>.
Hi Gabo
> Hi Sergey,
>
> Given he following:
>
> @WebService(name="MyService", targetNamespace="http://some.domain.com/")
> @SOAPBinding(use=Use.LITERAL, style=Style.RPC)
> @Consumes("text/xml")
> @Produces("text/xml")
> @Path("/")
> public interface MyService {
>
> @GET
> @Path("/search/")
> @WebMethod
> @WebResult(name="myObjects")
> public List<MyObject> getMyObjects(...);
> }
>
> and
>
> @XmlType(name="MyObject", namespace="http://some.domain.com")
> @XmlAccessorType(XmlAccessType.PROPERTY)
> @XmlRootElement(name="MyObject", namespace="http://some.domain.com")
> public class MyObject
>
> The object description is accurate. However, the method is displayed as follows:
>
> <resource path="/search/">
> <method name="GET">
> <request>
> ...
> </request>
> <response>
> <representation mediaType="text/xml"/>
> </response>
> </method>
> </resource>
>
> Are lists not supported for WADL?
I kind of referred to it a couple of times already. Basically, even though JAX-RS implementations do let people write resource
methods accepting/returning explicit collections, it is really a convinience hack which is something I've relied upon too in my own
JAX-RS services coding.
The question, what is the schema type for say Collection<Bar> ? Or Set<Foo> or List<Baz> ? CXF JAXRS JAXBElementProvider lets users
customize the name of the enclosing collection root, so it is really tricky to have a schema generated for say List<MyObject>.
If users would like to have their collections of JAXB types be described in WADLs then I'd recommend wrapping them, ex, in, say,
MyObjects JAXB class...
I might consider configuring the WADLGenerator such that it uses the registered JAXBProvider to get the actual JAXBContext
representing a given explicit collection and using it to have the schema generated...
hope it helps, Sergey
>
> Thanks in advance.
>
> Gabo
>
>
> Sergey Beryozkin wrote:
>> Hi Gabo
>>
>>> Hi Sergey,
>>>
>>> Sorry about that. But you did get the idea tho. :D
>>>
>>>> Is it the wadl:request element which has no links to the schema types ? If yes then it is expected when @Consumes is set to
>>>> */*, given that it may even be that only a non-XML format which is accepted by a method...
>>> Shouldn't the method still show some description of what the method is expecting? Maybe a redundancy of what was described in
>>> the grammar.
>>
>> See http://svn.apache.org/repos/asf/cxf/trunk/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/ext/Description.java
>>
>>>
>>> I would be trying having multiple specific values and update this thread of the results. Might take a while, got dragged to
>>> another task.
>>
>> Having @Consumes with multiple values will result in the generated WADL reflecting it. Same for @Produces.
>>
>> hope it helps, Sergey
>>
>>>
>>> Thanks again!
>>>
>>> Gabo
>>>
>>>>
>>>> cheers, Sergey
>>
Re: JAX-RS : initial WADL support
Posted by Gabo Manuel <km...@solegysystems.com>.
Hi Sergey,
Given he following:
@WebService(name="MyService", targetNamespace="http://some.domain.com/")
@SOAPBinding(use=Use.LITERAL, style=Style.RPC)
@Consumes("text/xml")
@Produces("text/xml")
@Path("/")
public interface MyService {
@GET
@Path("/search/")
@WebMethod
@WebResult(name="myObjects")
public List<MyObject> getMyObjects(...);
}
and
@XmlType(name="MyObject", namespace="http://some.domain.com")
@XmlAccessorType(XmlAccessType.PROPERTY)
@XmlRootElement(name="MyObject", namespace="http://some.domain.com")
public class MyObject
The object description is accurate. However, the method is displayed as
follows:
<resource path="/search/">
<method name="GET">
<request>
...
</request>
<response>
<representation mediaType="text/xml"/>
</response>
</method>
</resource>
Are lists not supported for WADL?
Thanks in advance.
Gabo
Sergey Beryozkin wrote:
> Hi Gabo
>
>> Hi Sergey,
>>
>> Sorry about that. But you did get the idea tho. :D
>>
>>> Is it the wadl:request element which has no links to the schema
>>> types ? If yes then it is expected when @Consumes is set to */*,
>>> given that it may even be that only a non-XML format which is
>>> accepted by a method...
>> Shouldn't the method still show some description of what the method
>> is expecting? Maybe a redundancy of what was described in the grammar.
>
> See
> http://svn.apache.org/repos/asf/cxf/trunk/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/ext/Description.java
>
>
>>
>> I would be trying having multiple specific values and update this
>> thread of the results. Might take a while, got dragged to another task.
>
> Having @Consumes with multiple values will result in the generated
> WADL reflecting it. Same for @Produces.
>
> hope it helps, Sergey
>
>>
>> Thanks again!
>>
>> Gabo
>>
>>>
>>> cheers, Sergey
>
Re: JAX-RS : initial WADL support
Posted by Sergey Beryozkin <sb...@progress.com>.
Hi Gabo
> Hi Sergey,
>
> Sorry about that. But you did get the idea tho. :D
>
>> Is it the wadl:request element which has no links to the schema types
>> ? If yes then it is expected when @Consumes is set to */*, given that
>> it may even be that only a non-XML format which is accepted by a
>> method...
> Shouldn't the method still show some description of what the method is
> expecting? Maybe a redundancy of what was described in the grammar.
See http://svn.apache.org/repos/asf/cxf/trunk/rt/frontend/jaxrs/src/main/java/org/apache/cxf/jaxrs/ext/Description.java
>
> I would be trying having multiple specific values and update this thread
> of the results. Might take a while, got dragged to another task.
Having @Consumes with multiple values will result in the generated WADL reflecting it. Same for @Produces.
hope it helps, Sergey
>
> Thanks again!
>
> Gabo
>
>>
>> cheers, Sergey
Re: JAX-RS : initial WADL support
Posted by Gabo Manuel <km...@solegysystems.com>.
Hi Sergey,
Sorry about that. But you did get the idea tho. :D
> Is it the wadl:request element which has no links to the schema types
> ? If yes then it is expected when @Consumes is set to */*, given that
> it may even be that only a non-XML format which is accepted by a
> method...
Shouldn't the method still show some description of what the method is
expecting? Maybe a redundancy of what was described in the grammar.
I would be trying having multiple specific values and update this thread
of the results. Might take a while, got dragged to another task.
Thanks again!
Gabo
>
> cheers, Sergey
Re: JAX-RS : initial WADL support
Posted by Sergey Beryozkin <sb...@progress.com>.
Hi Gabo
> Hi Sergey,
>
>
> Re: */*
>
> If I set the annotation @Consumes to */* and the @Produces to ("text/xml"), the wadl is not generated properly. I guess it is
> because of the difference between the two? In this case, is it really still advisable to have a separate annotation? I mean,
> shouldn't the annotation be reduced to 1 if it is required to have them as same values?
I'm sorry but it's been awhile since we discussed the actual issue you're seeing with the generated WADL...
Can you remind me please what exactly is happening ? Can you please post a sample resource class and method
(with @Consumes set to */* and the @Produces set to ("text/xml")) and clarify what is missing from the generated WADL ?
Is it the wadl:request element which has no links to the schema types ? If yes then it is expected when @Consumes is set to */*,
given that it may even be that only a non-XML format which is accepted by a method...
cheers, Sergey
>
> Gabo
>
> Sergey Beryozkin wrote:
>> Hi
>>
>>> Hi Sergey,
>>>
>>> Sorry for the delayed response to this thread. I am currently checking the generated WADL using 2.2.5. A few things I did to
>>> make it work:
>>>
>>> 1. Update consumes from */* to text/xml as the prior ends up showing only as:
>>>
>>> <request>
>>> <representation mediaType="*/*"/>
>>> </request>
>>>
>>> 2. have namespace in the XML-related annotation of each class. Have not tested yet relying on pagkage.info class yet.
>>>
>>> One thing though, see sample below:
>>>
>>> <representation mediaType="text/xml" element="prefix27:Route"/>
>>>
>>> The object Route is defined above, but the 'prefix27' part is not defined anywhere else. I think the same goes for 'xs' and
>>> 'tns' prefixes, is this ok?
>>
>> the corresponding namespaces must be declared at the wadl:application level, can you verify please ? Likewise "prefix27" must
>> poin to a namespace for one of the schemas in the grammars section. If you're looking at the generated wadl from the Firefox then
>> you need to tell it to show the actual page source...
>>
>>>
>>> Also, since I had to change */* to something more specifc, wouldn't this conflict with one of the major advantages of CXF, i.e.
>>> ability to automatically handle json, xml, etc without any other changes?
>>
>> Sorry, not sure what you mean. If your class has say application/xml & application/json produces values then the generated WADL
>> should have it reflected
>>
>>>
>>> Also, is it possible to configure somewhere to NOT apply the interceptors when viewing the wadl? I have my own implementation of
>>> http-auth digest and the password is being required whenever the wadl is being viewed. I was hoping it should be viewable
>>> without need of auth like wsdl.
>>
>> Can you interceptor check that it is a _wadl query and if yes then let the processing continue ?
>>
>> cheers, Sergey
Re: JAX-RS : initial WADL support
Posted by Gabo Manuel <km...@solegysystems.com>.
Hi Sergey,
Re: prefix definition
I tried to view page source, and the prefix definition is there. I think
this behavior is just with firefox, did not need to do this with IE.
Re: interceptor check for _wadl
Yep, did the same after I sent the email before.
Re: */*
If I set the annotation @Consumes to */* and the @Produces to
("text/xml"), the wadl is not generated properly. I guess it is because
of the difference between the two? In this case, is it really still
advisable to have a separate annotation? I mean, shouldn't the
annotation be reduced to 1 if it is required to have them as same values?
Gabo
Sergey Beryozkin wrote:
> Hi
>
>> Hi Sergey,
>>
>> Sorry for the delayed response to this thread. I am currently
>> checking the generated WADL using 2.2.5. A few things I did to make
>> it work:
>>
>> 1. Update consumes from */* to text/xml as the prior ends up showing
>> only as:
>>
>> <request>
>> <representation mediaType="*/*"/>
>> </request>
>>
>> 2. have namespace in the XML-related annotation of each class. Have
>> not tested yet relying on pagkage.info class yet.
>>
>> One thing though, see sample below:
>>
>> <representation mediaType="text/xml" element="prefix27:Route"/>
>>
>> The object Route is defined above, but the 'prefix27' part is not
>> defined anywhere else. I think the same goes for 'xs' and 'tns'
>> prefixes, is this ok?
>
> the corresponding namespaces must be declared at the wadl:application
> level, can you verify please ? Likewise "prefix27" must poin to a
> namespace for one of the schemas in the grammars section. If you're
> looking at the generated wadl from the Firefox then you need to tell
> it to show the actual page source...
>
>>
>> Also, since I had to change */* to something more specifc, wouldn't
>> this conflict with one of the major advantages of CXF, i.e. ability
>> to automatically handle json, xml, etc without any other changes?
>
> Sorry, not sure what you mean. If your class has say application/xml &
> application/json produces values then the generated WADL should have
> it reflected
>
>>
>> Also, is it possible to configure somewhere to NOT apply the
>> interceptors when viewing the wadl? I have my own implementation of
>> http-auth digest and the password is being required whenever the wadl
>> is being viewed. I was hoping it should be viewable without need of
>> auth like wsdl.
>
> Can you interceptor check that it is a _wadl query and if yes then let
> the processing continue ?
>
> cheers, Sergey
Re: JAX-RS : initial WADL support
Posted by Sergey Beryozkin <sb...@progress.com>.
Hi
> Hi Sergey,
>
> Sorry for the delayed response to this thread. I am currently checking the generated WADL using 2.2.5. A few things I did to make
> it work:
>
> 1. Update consumes from */* to text/xml as the prior ends up showing only as:
>
> <request>
> <representation mediaType="*/*"/>
> </request>
>
> 2. have namespace in the XML-related annotation of each class. Have not tested yet relying on pagkage.info class yet.
>
> One thing though, see sample below:
>
> <representation mediaType="text/xml" element="prefix27:Route"/>
>
> The object Route is defined above, but the 'prefix27' part is not defined anywhere else. I think the same goes for 'xs' and 'tns'
> prefixes, is this ok?
the corresponding namespaces must be declared at the wadl:application level, can you verify please ? Likewise "prefix27" must poin
to a namespace for one of the schemas in the grammars section. If you're looking at the generated wadl from the Firefox then you
need to tell it to show the actual page source...
>
> Also, since I had to change */* to something more specifc, wouldn't this conflict with one of the major advantages of CXF, i.e.
> ability to automatically handle json, xml, etc without any other changes?
Sorry, not sure what you mean. If your class has say application/xml & application/json produces values then the generated WADL
should have it reflected
>
> Also, is it possible to configure somewhere to NOT apply the interceptors when viewing the wadl? I have my own implementation of
> http-auth digest and the password is being required whenever the wadl is being viewed. I was hoping it should be viewable without
> need of auth like wsdl.
Can you interceptor check that it is a _wadl query and if yes then let the processing continue ?
cheers, Sergey
>
> Thanks again in advance.
>
> Gabo
>
> Sergey Beryozkin wrote:
>> Hi Gabo
>>
>>
>>> Hi Sergey,
>>>
>>> Thanks too! 2.2.4 then?
>>
>> Yeah, as far as the introspection of package-info.java is concerned. If you don't have many JAXB classes then simply add a
>> namespace to @XmlRootElements....If you really need it right now then you might want to register a custom WADLGenerator by
>> copying the code from the trunk, as a provider....
>>
>> cheers, Sergey
>>
>>>
>>> Also, to answer your question, this is the annotation used in the package-info class:
>>>
>>> @javax.xml.bind.annotation.XmlSchema(namespace = "http://domain.some/",
>>> elementFormDefault = javax.xml.bind.annotation.XmlNsForm.QUALIFIED)
>>>
>>> I just took this from the samples/user's guide.
>>>
>>> Gabo
>>>
>>> Sergey Beryozkin wrote:
>>>> Hi Gabo
>>>>
>>>> I've just got it fixed. WADLgenerator will now introspect package-info.java
>>>> in cases when @XmlRootElement has only a local name set and if the namespace
>>>> is available then the resulting WADL will correctly link to a generated
>>>> schema element....
>>>>
>>>> thanks for raising this issue
>>>> Sergey
>>>>
>>>>
>>>> Sergey Beryozkin wrote:
>>>>
>>>>> Hi Gabo
>>>>>
>>>>> MyObject has @XmlRootElement with only a local name specified. Does
>>>>> package-info.java has a namespace specified too, in addition to the local
>>>>> name ?
>>>>>
>>>>> cheers, Sergey
>>>>>
>>>>>
>>>>> Gabo Manuel wrote:
>>>>>
>>>>>> Hi Sergey,
>>>>>>
>>>>>> I am a bit confused. How do I supply the namespace needed? I thought the package-info.java would be enough.
>>>>>>
>>>>>> Yes, for now I would be limiting the consume to just text/xml. The initial intent was to take advantage of CXF's handling
>>>>>> between xml and json. But for now, we would be sticking to text/xml.
>>>>>>
>>>>>> Gabo
>>>>>>
>>>>>> Sergey Beryozkin wrote:
>>>>>>
>>>>>>> Hi Gabo
>>>>>>>
>>>>>>> thanks... The reason you only see the '<representation/>' for my MyObject is that
>>>>>>> there's no namespace available , so even though the <grammars/> section
>>>>>>> has
>>>>>>> the schema embedded there's no way to link to it from the
>>>>>>> <representation/>.
>>>>>>> May be I should have some XML comment generated which will advise to
>>>>>>> check
>>>>>>> the schema (with no namespace) ?
>>>>>>> You might also want to update Consumes("*/*") to require a more specific
>>>>>>> media type.
>>>>>>>
>>>>>>>
>>>>>>>> I haven't tried it lately without the providers, but are primitives now
>>>>>>>> supported out of the box?
>>>>>>>>
>>>>>>> They are but only for text/plain. I'll add a task to wrap them in some
>>>>>>> tag
>>>>>>> like <response> for xml media types
>>>>>>>
>>>>>>>
>>>>>>>> Also, is there somewhere to look to be able to use the tool that
>>>>>>>> creates
>>>>>>>> an http-centric client-code from the wadl?
>>>>>>>>
>>>>>>> No, I haven't started working on the code gen tool yet....But it's on
>>>>>>> the
>>>>>>> map
>>>>>>>
>>>>>>> cheers, Sergey
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Gabo Manuel wrote:
>>>>>>>
>>>>>>>> Hi Sergey,
>>>>>>>>
>>>>>>>> Sorry for the late response. I may have misrepresented the method, it should be as follows:
>>>>>>>>
>>>>>>>> @WebService(name="MyObjectService")
>>>>>>>> @SOAPBinding(use=Use.LITERAL, style=Style.RPC)
>>>>>>>> @Consumes("*/*")
>>>>>>>> @Produces("text/xml")
>>>>>>>> @Path("/MyObjects")
>>>>>>>> public interface MyObjectService{
>>>>>>>> @GET
>>>>>>>> @Path("/")
>>>>>>>> @WebMethod
>>>>>>>> @WebResult(name="myObjectInstance")
>>>>>>>> public MyObject getMyObject(
>>>>>>>> @QueryParam("uniqueIDField")
>>>>>>>> @WebParam(name="uniqueIDField")
>>>>>>>> long uniqueIDField)
>>>>>>>> ;
>>>>>>>>
>>>>>>>> @PUT
>>>>>>>> @Path("/")
>>>>>>>> @WebMethod
>>>>>>>> @WebResult(name="uniqueIDField")
>>>>>>>> public long insertMyObject(
>>>>>>>> @WebParam(name="myObjectInstance")
>>>>>>>> MyObject myObjectInstance,
>>>>>>>> @QueryParam("reason")
>>>>>>>> @WebParam(name="reason")
>>>>>>>> String reason
>>>>>>>> )
>>>>>>>> ;
>>>>>>>> }
>>>>>>>>
>>>>>>>> @WebService(endpointInterface="some.domain.MyObjectService", serviceName="MyObjectService", portName="MyObjectServicePort")
>>>>>>>> public class MyObjectServiceImpl implements MyObjectService{
>>>>>>>> public MyObject getMyObject(long uniqueIDField) throws SolegyContingencyException{
>>>>>>>> return new MyObject();
>>>>>>>> }
>>>>>>>> public long insertMyObject(MyObject myObjectInstance, String
>>>>>>>> reason) throws SolegyContingencyException{
>>>>>>>> return 1;
>>>>>>>> }
>>>>>>>> }
>>>>>>>>
>>>>>>>> @XmlType(name="MyObject")
>>>>>>>> @XmlAccessorType(XmlAccessType.PROPERTY)
>>>>>>>> @XmlRootElement(name="MyObject")
>>>>>>>> public class MyObject {
>>>>>>>> private long uniqueIDField;
>>>>>>>> @GET
>>>>>>>> @Path("/uniqueIDField")
>>>>>>>> public long getUniqueIDField() {
>>>>>>>> return uniqueIDField;
>>>>>>>> }
>>>>>>>> public void setUniqueIDField(long uniqueIDField) {
>>>>>>>> this.uniqueIDField = uniqueIDField;
>>>>>>>> }
>>>>>>>> }
>>>>>>>>
>>>>>>>> The wadl section i get is something as follows:
>>>>>>>>
>>>>>>>> <method name="GET">
>>>>>>>> <request>
>>>>>>>> </request>
>>>>>>>> <response>
>>>>>>>> <representation mediaType="text/xml"/>
>>>>>>>> </response>
>>>>>>>> </method>
>>>>>>>> <method name="PUT">
>>>>>>>> <request>
>>>>>>>> <representation/>
>>>>>>>> </request>
>>>>>>>> <response>
>>>>>>>> <!-- Primitive type : xs:long --><representation
>>>>>>>> mediaType="text/xml"/>
>>>>>>>> </response>
>>>>>>>> </method>
>>>>>>>>
>>>>>>>> And yes, I did specify text/xml. I also have providers included to wrap the response in tags. I had to add the providers
>>>>>>>> because at the time (2.0), primitives were not supported. I haven't tried it lately without the providers, but are
>>>>>>>> primitives now supported out of the box?
>>>>>>>>
>>>>>>>> Also, is there somewhere to look to be able to use the tool that
>>>>>>>> creates an http-centric client-code from the wadl?
>>>>>>>>
>>>>>>>> Thanks!
>>>>>>>>
>>>>>>>> Gabo.
>>>>>>>>
>>>>>>>> Sergey Beryozkin wrote:
>>>>>>>>
>>>>>>>>> Hi Gabo
>>>>>>>>>
>>>>>>>>> It is an 'Object' so a WSDL generator has no idea what else to say,
>>>>>>>>> apart
>>>>>>>>> from <representation/>. If you add "Consumes' with some values then
>>>>>>>>> you'll
>>>>>>>>> get a bit more specific tag...
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> However, there appears to be a bug :
>>>>>>>>>
>>>>>>>>> <response><!-- Primitive type : xs:long --><representation
>>>>>>>>> mediaType="text/xml"/></response></method></resource>
>>>>>>>>>
>>>>>>>>> or do you have Produces('text/xml') on the class itself ? Can you
>>>>>>>>> please
>>>>>>>>> send me a class sample so that I can fix it ?
>>>>>>>>>
>>>>>>>>> cheers, Sergey
>>>>>>>>>
>>>>>>>>
>>>>>>> ------------------------------------------------------------------------
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> No virus found in this incoming message.
>>>>>>> Checked by AVG - www.avg.com Version: 8.5.409 / Virus Database: 270.13.62/2315 - Release Date:
>>>>>>> 08/20/09 06:05:00
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>>
>>>> No virus found in this incoming message.
>>>> Checked by AVG - www.avg.com Version: 8.5.409 / Virus Database: 270.13.65/2323 - Release Date: 08/24/09 06:05:00
>>>>
>>>>
>> ------------------------------------------------------------------------
>>
>>
>> No virus found in this incoming message.
>> Checked by AVG - www.avg.com Version: 8.5.409 / Virus Database: 270.13.66/2325 - Release Date: 08/25/09 06:08:00
>>
>>
Re: JAX-RS : initial WADL support
Posted by Gabo Manuel <km...@solegysystems.com>.
Hi Sergey,
Sorry for the delayed response to this thread. I am currently checking
the generated WADL using 2.2.5. A few things I did to make it work:
1. Update consumes from */* to text/xml as the prior ends up showing
only as:
<request>
<representation mediaType="*/*"/>
</request>
2. have namespace in the XML-related annotation of each class. Have not
tested yet relying on pagkage.info class yet.
One thing though, see sample below:
<representation mediaType="text/xml" element="prefix27:Route"/>
The object Route is defined above, but the 'prefix27' part is not
defined anywhere else. I think the same goes for 'xs' and 'tns'
prefixes, is this ok?
Also, since I had to change */* to something more specifc, wouldn't this
conflict with one of the major advantages of CXF, i.e. ability to
automatically handle json, xml, etc without any other changes?
Also, is it possible to configure somewhere to NOT apply the
interceptors when viewing the wadl? I have my own implementation of
http-auth digest and the password is being required whenever the wadl is
being viewed. I was hoping it should be viewable without need of auth
like wsdl.
Thanks again in advance.
Gabo
Sergey Beryozkin wrote:
> Hi Gabo
>
>
>> Hi Sergey,
>>
>> Thanks too! 2.2.4 then?
>
> Yeah, as far as the introspection of package-info.java is concerned.
> If you don't have many JAXB classes then simply add a namespace to
> @XmlRootElements....If you really need it right now then you might
> want to register a custom WADLGenerator by copying the code from the
> trunk, as a provider....
>
> cheers, Sergey
>
>>
>> Also, to answer your question, this is the annotation used in the
>> package-info class:
>>
>> @javax.xml.bind.annotation.XmlSchema(namespace = "http://domain.some/",
>> elementFormDefault =
>> javax.xml.bind.annotation.XmlNsForm.QUALIFIED)
>>
>> I just took this from the samples/user's guide.
>>
>> Gabo
>>
>> Sergey Beryozkin wrote:
>>> Hi Gabo
>>>
>>> I've just got it fixed. WADLgenerator will now introspect
>>> package-info.java
>>> in cases when @XmlRootElement has only a local name set and if the
>>> namespace
>>> is available then the resulting WADL will correctly link to a generated
>>> schema element....
>>>
>>> thanks for raising this issue
>>> Sergey
>>>
>>>
>>> Sergey Beryozkin wrote:
>>>
>>>> Hi Gabo
>>>>
>>>> MyObject has @XmlRootElement with only a local name specified. Does
>>>> package-info.java has a namespace specified too, in addition to the
>>>> local
>>>> name ?
>>>>
>>>> cheers, Sergey
>>>>
>>>>
>>>> Gabo Manuel wrote:
>>>>
>>>>> Hi Sergey,
>>>>>
>>>>> I am a bit confused. How do I supply the namespace needed? I
>>>>> thought the package-info.java would be enough.
>>>>>
>>>>> Yes, for now I would be limiting the consume to just text/xml. The
>>>>> initial intent was to take advantage of CXF's handling between xml
>>>>> and json. But for now, we would be sticking to text/xml.
>>>>>
>>>>> Gabo
>>>>>
>>>>> Sergey Beryozkin wrote:
>>>>>
>>>>>> Hi Gabo
>>>>>>
>>>>>> thanks... The reason you only see the '<representation/>' for my
>>>>>> MyObject is that
>>>>>> there's no namespace available , so even though the <grammars/>
>>>>>> section
>>>>>> has
>>>>>> the schema embedded there's no way to link to it from the
>>>>>> <representation/>.
>>>>>> May be I should have some XML comment generated which will advise to
>>>>>> check
>>>>>> the schema (with no namespace) ?
>>>>>> You might also want to update Consumes("*/*") to require a more
>>>>>> specific
>>>>>> media type.
>>>>>>
>>>>>>
>>>>>>> I haven't tried it lately without the providers, but are
>>>>>>> primitives now
>>>>>>> supported out of the box?
>>>>>>>
>>>>>> They are but only for text/plain. I'll add a task to wrap them in
>>>>>> some
>>>>>> tag
>>>>>> like <response> for xml media types
>>>>>>
>>>>>>
>>>>>>> Also, is there somewhere to look to be able to use the tool that
>>>>>>> creates
>>>>>>> an http-centric client-code from the wadl?
>>>>>>>
>>>>>> No, I haven't started working on the code gen tool yet....But
>>>>>> it's on
>>>>>> the
>>>>>> map
>>>>>>
>>>>>> cheers, Sergey
>>>>>>
>>>>>>
>>>>>>
>>>>>> Gabo Manuel wrote:
>>>>>>
>>>>>>> Hi Sergey,
>>>>>>>
>>>>>>> Sorry for the late response. I may have misrepresented the
>>>>>>> method, it should be as follows:
>>>>>>>
>>>>>>> @WebService(name="MyObjectService")
>>>>>>> @SOAPBinding(use=Use.LITERAL, style=Style.RPC)
>>>>>>> @Consumes("*/*")
>>>>>>> @Produces("text/xml")
>>>>>>> @Path("/MyObjects")
>>>>>>> public interface MyObjectService{
>>>>>>> @GET
>>>>>>> @Path("/")
>>>>>>> @WebMethod
>>>>>>> @WebResult(name="myObjectInstance")
>>>>>>> public MyObject getMyObject(
>>>>>>> @QueryParam("uniqueIDField")
>>>>>>> @WebParam(name="uniqueIDField")
>>>>>>> long uniqueIDField)
>>>>>>> ;
>>>>>>>
>>>>>>> @PUT
>>>>>>> @Path("/")
>>>>>>> @WebMethod
>>>>>>> @WebResult(name="uniqueIDField")
>>>>>>> public long insertMyObject(
>>>>>>> @WebParam(name="myObjectInstance")
>>>>>>> MyObject myObjectInstance,
>>>>>>> @QueryParam("reason")
>>>>>>> @WebParam(name="reason")
>>>>>>> String reason
>>>>>>> )
>>>>>>> ;
>>>>>>> }
>>>>>>>
>>>>>>> @WebService(endpointInterface="some.domain.MyObjectService",
>>>>>>> serviceName="MyObjectService", portName="MyObjectServicePort")
>>>>>>> public class MyObjectServiceImpl implements MyObjectService{
>>>>>>> public MyObject getMyObject(long uniqueIDField) throws
>>>>>>> SolegyContingencyException{
>>>>>>> return new MyObject();
>>>>>>> }
>>>>>>> public long insertMyObject(MyObject myObjectInstance, String
>>>>>>> reason) throws SolegyContingencyException{
>>>>>>> return 1;
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>> @XmlType(name="MyObject")
>>>>>>> @XmlAccessorType(XmlAccessType.PROPERTY)
>>>>>>> @XmlRootElement(name="MyObject")
>>>>>>> public class MyObject {
>>>>>>> private long uniqueIDField;
>>>>>>> @GET
>>>>>>> @Path("/uniqueIDField")
>>>>>>> public long getUniqueIDField() {
>>>>>>> return uniqueIDField;
>>>>>>> }
>>>>>>> public void setUniqueIDField(long uniqueIDField) {
>>>>>>> this.uniqueIDField = uniqueIDField;
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>> The wadl section i get is something as follows:
>>>>>>>
>>>>>>> <method name="GET">
>>>>>>> <request>
>>>>>>> </request>
>>>>>>> <response>
>>>>>>> <representation mediaType="text/xml"/>
>>>>>>> </response>
>>>>>>> </method>
>>>>>>> <method name="PUT">
>>>>>>> <request>
>>>>>>> <representation/>
>>>>>>> </request>
>>>>>>> <response>
>>>>>>> <!-- Primitive type : xs:long --><representation
>>>>>>> mediaType="text/xml"/>
>>>>>>> </response>
>>>>>>> </method>
>>>>>>>
>>>>>>> And yes, I did specify text/xml. I also have providers included
>>>>>>> to wrap the response in tags. I had to add the providers because
>>>>>>> at the time (2.0), primitives were not supported. I haven't
>>>>>>> tried it lately without the providers, but are primitives now
>>>>>>> supported out of the box?
>>>>>>>
>>>>>>> Also, is there somewhere to look to be able to use the tool that
>>>>>>> creates an http-centric client-code from the wadl?
>>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>> Gabo.
>>>>>>>
>>>>>>> Sergey Beryozkin wrote:
>>>>>>>
>>>>>>>> Hi Gabo
>>>>>>>>
>>>>>>>> It is an 'Object' so a WSDL generator has no idea what else to
>>>>>>>> say,
>>>>>>>> apart
>>>>>>>> from <representation/>. If you add "Consumes' with some values
>>>>>>>> then
>>>>>>>> you'll
>>>>>>>> get a bit more specific tag...
>>>>>>>>
>>>>>>>>
>>>>>>>> However, there appears to be a bug :
>>>>>>>>
>>>>>>>> <response><!-- Primitive type : xs:long --><representation
>>>>>>>> mediaType="text/xml"/></response></method></resource>
>>>>>>>>
>>>>>>>> or do you have Produces('text/xml') on the class itself ? Can you
>>>>>>>> please
>>>>>>>> send me a class sample so that I can fix it ?
>>>>>>>>
>>>>>>>> cheers, Sergey
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------
>>>>>>
>>>>>>
>>>>>>
>>>>>> No virus found in this incoming message.
>>>>>> Checked by AVG - www.avg.com Version: 8.5.409 / Virus Database:
>>>>>> 270.13.62/2315 - Release Date:
>>>>>> 08/20/09 06:05:00
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>>
>>> No virus found in this incoming message.
>>> Checked by AVG - www.avg.com Version: 8.5.409 / Virus Database:
>>> 270.13.65/2323 - Release Date: 08/24/09 06:05:00
>>>
>>>
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.409 / Virus Database: 270.13.66/2325 - Release Date: 08/25/09 06:08:00
>
>
Re: JAX-RS : initial WADL support
Posted by Sergey Beryozkin <sb...@progress.com>.
Hi Gabo
> Hi Sergey,
>
> Thanks too! 2.2.4 then?
Yeah, as far as the introspection of package-info.java is concerned. If you don't have many JAXB classes then simply add a namespace
to @XmlRootElements....If you really need it right now then you might want to register a custom WADLGenerator by copying the code
from the trunk, as a provider....
cheers, Sergey
>
> Also, to answer your question, this is the annotation used in the package-info class:
>
> @javax.xml.bind.annotation.XmlSchema(namespace = "http://domain.some/",
> elementFormDefault = javax.xml.bind.annotation.XmlNsForm.QUALIFIED)
>
> I just took this from the samples/user's guide.
>
> Gabo
>
> Sergey Beryozkin wrote:
>> Hi Gabo
>>
>> I've just got it fixed. WADLgenerator will now introspect package-info.java
>> in cases when @XmlRootElement has only a local name set and if the namespace
>> is available then the resulting WADL will correctly link to a generated
>> schema element....
>>
>> thanks for raising this issue
>> Sergey
>>
>>
>> Sergey Beryozkin wrote:
>>
>>> Hi Gabo
>>>
>>> MyObject has @XmlRootElement with only a local name specified. Does
>>> package-info.java has a namespace specified too, in addition to the local
>>> name ?
>>>
>>> cheers, Sergey
>>>
>>>
>>> Gabo Manuel wrote:
>>>
>>>> Hi Sergey,
>>>>
>>>> I am a bit confused. How do I supply the namespace needed? I thought the package-info.java would be enough.
>>>>
>>>> Yes, for now I would be limiting the consume to just text/xml. The initial intent was to take advantage of CXF's handling
>>>> between xml and json. But for now, we would be sticking to text/xml.
>>>>
>>>> Gabo
>>>>
>>>> Sergey Beryozkin wrote:
>>>>
>>>>> Hi Gabo
>>>>>
>>>>> thanks... The reason you only see the '<representation/>' for my MyObject is that
>>>>> there's no namespace available , so even though the <grammars/> section
>>>>> has
>>>>> the schema embedded there's no way to link to it from the
>>>>> <representation/>.
>>>>> May be I should have some XML comment generated which will advise to
>>>>> check
>>>>> the schema (with no namespace) ?
>>>>> You might also want to update Consumes("*/*") to require a more specific
>>>>> media type.
>>>>>
>>>>>
>>>>>> I haven't tried it lately without the providers, but are primitives now
>>>>>> supported out of the box?
>>>>>>
>>>>> They are but only for text/plain. I'll add a task to wrap them in some
>>>>> tag
>>>>> like <response> for xml media types
>>>>>
>>>>>
>>>>>> Also, is there somewhere to look to be able to use the tool that
>>>>>> creates
>>>>>> an http-centric client-code from the wadl?
>>>>>>
>>>>> No, I haven't started working on the code gen tool yet....But it's on
>>>>> the
>>>>> map
>>>>>
>>>>> cheers, Sergey
>>>>>
>>>>>
>>>>>
>>>>> Gabo Manuel wrote:
>>>>>
>>>>>> Hi Sergey,
>>>>>>
>>>>>> Sorry for the late response. I may have misrepresented the method, it should be as follows:
>>>>>>
>>>>>> @WebService(name="MyObjectService")
>>>>>> @SOAPBinding(use=Use.LITERAL, style=Style.RPC)
>>>>>> @Consumes("*/*")
>>>>>> @Produces("text/xml")
>>>>>> @Path("/MyObjects")
>>>>>> public interface MyObjectService{
>>>>>> @GET
>>>>>> @Path("/")
>>>>>> @WebMethod
>>>>>> @WebResult(name="myObjectInstance")
>>>>>> public MyObject getMyObject(
>>>>>> @QueryParam("uniqueIDField")
>>>>>> @WebParam(name="uniqueIDField")
>>>>>> long uniqueIDField)
>>>>>> ;
>>>>>>
>>>>>> @PUT
>>>>>> @Path("/")
>>>>>> @WebMethod
>>>>>> @WebResult(name="uniqueIDField")
>>>>>> public long insertMyObject(
>>>>>> @WebParam(name="myObjectInstance")
>>>>>> MyObject myObjectInstance,
>>>>>> @QueryParam("reason")
>>>>>> @WebParam(name="reason")
>>>>>> String reason
>>>>>> )
>>>>>> ;
>>>>>> }
>>>>>>
>>>>>> @WebService(endpointInterface="some.domain.MyObjectService", serviceName="MyObjectService", portName="MyObjectServicePort")
>>>>>> public class MyObjectServiceImpl implements MyObjectService{
>>>>>> public MyObject getMyObject(long uniqueIDField) throws SolegyContingencyException{
>>>>>> return new MyObject();
>>>>>> }
>>>>>> public long insertMyObject(MyObject myObjectInstance, String
>>>>>> reason) throws SolegyContingencyException{
>>>>>> return 1;
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> @XmlType(name="MyObject")
>>>>>> @XmlAccessorType(XmlAccessType.PROPERTY)
>>>>>> @XmlRootElement(name="MyObject")
>>>>>> public class MyObject {
>>>>>> private long uniqueIDField;
>>>>>> @GET
>>>>>> @Path("/uniqueIDField")
>>>>>> public long getUniqueIDField() {
>>>>>> return uniqueIDField;
>>>>>> }
>>>>>> public void setUniqueIDField(long uniqueIDField) {
>>>>>> this.uniqueIDField = uniqueIDField;
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> The wadl section i get is something as follows:
>>>>>>
>>>>>> <method name="GET">
>>>>>> <request>
>>>>>> </request>
>>>>>> <response>
>>>>>> <representation mediaType="text/xml"/>
>>>>>> </response>
>>>>>> </method>
>>>>>> <method name="PUT">
>>>>>> <request>
>>>>>> <representation/>
>>>>>> </request>
>>>>>> <response>
>>>>>> <!-- Primitive type : xs:long --><representation
>>>>>> mediaType="text/xml"/>
>>>>>> </response>
>>>>>> </method>
>>>>>>
>>>>>> And yes, I did specify text/xml. I also have providers included to wrap the response in tags. I had to add the providers
>>>>>> because at the time (2.0), primitives were not supported. I haven't tried it lately without the providers, but are primitives
>>>>>> now supported out of the box?
>>>>>>
>>>>>> Also, is there somewhere to look to be able to use the tool that
>>>>>> creates an http-centric client-code from the wadl?
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> Gabo.
>>>>>>
>>>>>> Sergey Beryozkin wrote:
>>>>>>
>>>>>>> Hi Gabo
>>>>>>>
>>>>>>> It is an 'Object' so a WSDL generator has no idea what else to say,
>>>>>>> apart
>>>>>>> from <representation/>. If you add "Consumes' with some values then
>>>>>>> you'll
>>>>>>> get a bit more specific tag...
>>>>>>>
>>>>>>>
>>>>>>> However, there appears to be a bug :
>>>>>>>
>>>>>>> <response><!-- Primitive type : xs:long --><representation
>>>>>>> mediaType="text/xml"/></response></method></resource>
>>>>>>>
>>>>>>> or do you have Produces('text/xml') on the class itself ? Can you
>>>>>>> please
>>>>>>> send me a class sample so that I can fix it ?
>>>>>>>
>>>>>>> cheers, Sergey
>>>>>>>
>>>>>>
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>>
>>>>> No virus found in this incoming message.
>>>>> Checked by AVG - www.avg.com Version: 8.5.409 / Virus Database: 270.13.62/2315 - Release Date:
>>>>> 08/20/09 06:05:00
>>>>>
>>>>>
>>>>
>>>
>>
>> ------------------------------------------------------------------------
>>
>>
>> No virus found in this incoming message.
>> Checked by AVG - www.avg.com Version: 8.5.409 / Virus Database: 270.13.65/2323 - Release Date: 08/24/09 06:05:00
>>
>>
Re: JAX-RS : initial WADL support
Posted by Gabo Manuel <km...@solegysystems.com>.
Hi Sergey,
Thanks too! 2.2.4 then?
Also, to answer your question, this is the annotation used in the
package-info class:
@javax.xml.bind.annotation.XmlSchema(namespace = "http://domain.some/",
elementFormDefault =
javax.xml.bind.annotation.XmlNsForm.QUALIFIED)
I just took this from the samples/user's guide.
Gabo
Sergey Beryozkin wrote:
> Hi Gabo
>
> I've just got it fixed. WADLgenerator will now introspect package-info.java
> in cases when @XmlRootElement has only a local name set and if the namespace
> is available then the resulting WADL will correctly link to a generated
> schema element....
>
> thanks for raising this issue
> Sergey
>
>
> Sergey Beryozkin wrote:
>
>> Hi Gabo
>>
>> MyObject has @XmlRootElement with only a local name specified. Does
>> package-info.java has a namespace specified too, in addition to the local
>> name ?
>>
>> cheers, Sergey
>>
>>
>> Gabo Manuel wrote:
>>
>>> Hi Sergey,
>>>
>>> I am a bit confused. How do I supply the namespace needed? I thought the
>>> package-info.java would be enough.
>>>
>>> Yes, for now I would be limiting the consume to just text/xml. The
>>> initial intent was to take advantage of CXF's handling between xml and
>>> json. But for now, we would be sticking to text/xml.
>>>
>>> Gabo
>>>
>>> Sergey Beryozkin wrote:
>>>
>>>> Hi Gabo
>>>>
>>>> thanks...
>>>> The reason you only see the '<representation/>' for my MyObject is that
>>>> there's no namespace available , so even though the <grammars/> section
>>>> has
>>>> the schema embedded there's no way to link to it from the
>>>> <representation/>.
>>>> May be I should have some XML comment generated which will advise to
>>>> check
>>>> the schema (with no namespace) ?
>>>>
>>>> You might also want to update Consumes("*/*") to require a more specific
>>>> media type.
>>>>
>>>>
>>>>
>>>>> I haven't tried it lately without the providers, but are primitives now
>>>>> supported out of the box?
>>>>>
>>>>>
>>>> They are but only for text/plain. I'll add a task to wrap them in some
>>>> tag
>>>> like <response> for xml media types
>>>>
>>>>
>>>>
>>>>> Also, is there somewhere to look to be able to use the tool that
>>>>> creates
>>>>> an http-centric client-code from the wadl?
>>>>>
>>>>>
>>>> No, I haven't started working on the code gen tool yet....But it's on
>>>> the
>>>> map
>>>>
>>>> cheers, Sergey
>>>>
>>>>
>>>>
>>>> Gabo Manuel wrote:
>>>>
>>>>
>>>>> Hi Sergey,
>>>>>
>>>>> Sorry for the late response. I may have misrepresented the method, it
>>>>> should be as follows:
>>>>>
>>>>> @WebService(name="MyObjectService")
>>>>> @SOAPBinding(use=Use.LITERAL, style=Style.RPC)
>>>>> @Consumes("*/*")
>>>>> @Produces("text/xml")
>>>>> @Path("/MyObjects")
>>>>> public interface MyObjectService{
>>>>> @GET
>>>>> @Path("/")
>>>>> @WebMethod
>>>>> @WebResult(name="myObjectInstance")
>>>>> public MyObject getMyObject(
>>>>> @QueryParam("uniqueIDField")
>>>>> @WebParam(name="uniqueIDField")
>>>>> long uniqueIDField)
>>>>> ;
>>>>>
>>>>> @PUT
>>>>> @Path("/")
>>>>> @WebMethod
>>>>> @WebResult(name="uniqueIDField")
>>>>> public long insertMyObject(
>>>>> @WebParam(name="myObjectInstance")
>>>>> MyObject myObjectInstance,
>>>>> @QueryParam("reason")
>>>>> @WebParam(name="reason")
>>>>> String reason
>>>>> )
>>>>> ;
>>>>> }
>>>>>
>>>>> @WebService(endpointInterface="some.domain.MyObjectService",
>>>>> serviceName="MyObjectService", portName="MyObjectServicePort")
>>>>> public class MyObjectServiceImpl implements MyObjectService{
>>>>> public MyObject getMyObject(long uniqueIDField) throws
>>>>> SolegyContingencyException{
>>>>> return new MyObject();
>>>>> }
>>>>> public long insertMyObject(MyObject myObjectInstance, String
>>>>> reason)
>>>>> throws SolegyContingencyException{
>>>>> return 1;
>>>>> }
>>>>> }
>>>>>
>>>>> @XmlType(name="MyObject")
>>>>> @XmlAccessorType(XmlAccessType.PROPERTY)
>>>>> @XmlRootElement(name="MyObject")
>>>>> public class MyObject {
>>>>> private long uniqueIDField;
>>>>> @GET
>>>>> @Path("/uniqueIDField")
>>>>> public long getUniqueIDField() {
>>>>> return uniqueIDField;
>>>>> }
>>>>> public void setUniqueIDField(long uniqueIDField) {
>>>>> this.uniqueIDField = uniqueIDField;
>>>>> }
>>>>> }
>>>>>
>>>>> The wadl section i get is something as follows:
>>>>>
>>>>> <method name="GET">
>>>>> <request>
>>>>>
>>>>> </request>
>>>>> <response>
>>>>> <representation mediaType="text/xml"/>
>>>>> </response>
>>>>> </method>
>>>>> <method name="PUT">
>>>>> <request>
>>>>> <representation/>
>>>>>
>>>>> </request>
>>>>> <response>
>>>>> <!-- Primitive type : xs:long --><representation
>>>>> mediaType="text/xml"/>
>>>>> </response>
>>>>> </method>
>>>>>
>>>>> And yes, I did specify text/xml. I also have providers included to wrap
>>>>> the response in tags. I had to add the providers because at the time
>>>>> (2.0), primitives were not supported. I haven't tried it lately without
>>>>> the providers, but are primitives now supported out of the box?
>>>>>
>>>>> Also, is there somewhere to look to be able to use the tool that
>>>>> creates
>>>>> an http-centric client-code from the wadl?
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Gabo.
>>>>>
>>>>> Sergey Beryozkin wrote:
>>>>>
>>>>>
>>>>>> Hi Gabo
>>>>>>
>>>>>> It is an 'Object' so a WSDL generator has no idea what else to say,
>>>>>> apart
>>>>>> from <representation/>. If you add "Consumes' with some values then
>>>>>> you'll
>>>>>> get a bit more specific tag...
>>>>>>
>>>>>>
>>>>>> However, there appears to be a bug :
>>>>>>
>>>>>> <response><!-- Primitive type : xs:long
>>>>>> --><representation
>>>>>> mediaType="text/xml"/></response></method></resource>
>>>>>>
>>>>>> or do you have Produces('text/xml') on the class itself ? Can you
>>>>>> please
>>>>>> send me a class sample so that I can fix it ?
>>>>>>
>>>>>> cheers, Sergey
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>> No virus found in this incoming message.
>>>> Checked by AVG - www.avg.com
>>>> Version: 8.5.409 / Virus Database: 270.13.62/2315 - Release Date:
>>>> 08/20/09 06:05:00
>>>>
>>>>
>>>>
>>>
>>
>
>
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.409 / Virus Database: 270.13.65/2323 - Release Date: 08/24/09 06:05:00
>
>
Re: JAX-RS : initial WADL support
Posted by Sergey Beryozkin <se...@iona.com>.
Hi Gabo
I've just got it fixed. WADLgenerator will now introspect package-info.java
in cases when @XmlRootElement has only a local name set and if the namespace
is available then the resulting WADL will correctly link to a generated
schema element....
thanks for raising this issue
Sergey
Sergey Beryozkin wrote:
>
> Hi Gabo
>
> MyObject has @XmlRootElement with only a local name specified. Does
> package-info.java has a namespace specified too, in addition to the local
> name ?
>
> cheers, Sergey
>
>
> Gabo Manuel wrote:
>>
>> Hi Sergey,
>>
>> I am a bit confused. How do I supply the namespace needed? I thought the
>> package-info.java would be enough.
>>
>> Yes, for now I would be limiting the consume to just text/xml. The
>> initial intent was to take advantage of CXF's handling between xml and
>> json. But for now, we would be sticking to text/xml.
>>
>> Gabo
>>
>> Sergey Beryozkin wrote:
>>> Hi Gabo
>>>
>>> thanks...
>>> The reason you only see the '<representation/>' for my MyObject is that
>>> there's no namespace available , so even though the <grammars/> section
>>> has
>>> the schema embedded there's no way to link to it from the
>>> <representation/>.
>>> May be I should have some XML comment generated which will advise to
>>> check
>>> the schema (with no namespace) ?
>>>
>>> You might also want to update Consumes("*/*") to require a more specific
>>> media type.
>>>
>>>
>>>> I haven't tried it lately without the providers, but are primitives now
>>>> supported out of the box?
>>>>
>>>
>>> They are but only for text/plain. I'll add a task to wrap them in some
>>> tag
>>> like <response> for xml media types
>>>
>>>
>>>> Also, is there somewhere to look to be able to use the tool that
>>>> creates
>>>> an http-centric client-code from the wadl?
>>>>
>>>
>>> No, I haven't started working on the code gen tool yet....But it's on
>>> the
>>> map
>>>
>>> cheers, Sergey
>>>
>>>
>>>
>>> Gabo Manuel wrote:
>>>
>>>> Hi Sergey,
>>>>
>>>> Sorry for the late response. I may have misrepresented the method, it
>>>> should be as follows:
>>>>
>>>> @WebService(name="MyObjectService")
>>>> @SOAPBinding(use=Use.LITERAL, style=Style.RPC)
>>>> @Consumes("*/*")
>>>> @Produces("text/xml")
>>>> @Path("/MyObjects")
>>>> public interface MyObjectService{
>>>> @GET
>>>> @Path("/")
>>>> @WebMethod
>>>> @WebResult(name="myObjectInstance")
>>>> public MyObject getMyObject(
>>>> @QueryParam("uniqueIDField")
>>>> @WebParam(name="uniqueIDField")
>>>> long uniqueIDField)
>>>> ;
>>>>
>>>> @PUT
>>>> @Path("/")
>>>> @WebMethod
>>>> @WebResult(name="uniqueIDField")
>>>> public long insertMyObject(
>>>> @WebParam(name="myObjectInstance")
>>>> MyObject myObjectInstance,
>>>> @QueryParam("reason")
>>>> @WebParam(name="reason")
>>>> String reason
>>>> )
>>>> ;
>>>> }
>>>>
>>>> @WebService(endpointInterface="some.domain.MyObjectService",
>>>> serviceName="MyObjectService", portName="MyObjectServicePort")
>>>> public class MyObjectServiceImpl implements MyObjectService{
>>>> public MyObject getMyObject(long uniqueIDField) throws
>>>> SolegyContingencyException{
>>>> return new MyObject();
>>>> }
>>>> public long insertMyObject(MyObject myObjectInstance, String
>>>> reason)
>>>> throws SolegyContingencyException{
>>>> return 1;
>>>> }
>>>> }
>>>>
>>>> @XmlType(name="MyObject")
>>>> @XmlAccessorType(XmlAccessType.PROPERTY)
>>>> @XmlRootElement(name="MyObject")
>>>> public class MyObject {
>>>> private long uniqueIDField;
>>>> @GET
>>>> @Path("/uniqueIDField")
>>>> public long getUniqueIDField() {
>>>> return uniqueIDField;
>>>> }
>>>> public void setUniqueIDField(long uniqueIDField) {
>>>> this.uniqueIDField = uniqueIDField;
>>>> }
>>>> }
>>>>
>>>> The wadl section i get is something as follows:
>>>>
>>>> <method name="GET">
>>>> <request>
>>>>
>>>> </request>
>>>> <response>
>>>> <representation mediaType="text/xml"/>
>>>> </response>
>>>> </method>
>>>> <method name="PUT">
>>>> <request>
>>>> <representation/>
>>>>
>>>> </request>
>>>> <response>
>>>> <!-- Primitive type : xs:long --><representation
>>>> mediaType="text/xml"/>
>>>> </response>
>>>> </method>
>>>>
>>>> And yes, I did specify text/xml. I also have providers included to wrap
>>>> the response in tags. I had to add the providers because at the time
>>>> (2.0), primitives were not supported. I haven't tried it lately without
>>>> the providers, but are primitives now supported out of the box?
>>>>
>>>> Also, is there somewhere to look to be able to use the tool that
>>>> creates
>>>> an http-centric client-code from the wadl?
>>>>
>>>> Thanks!
>>>>
>>>> Gabo.
>>>>
>>>> Sergey Beryozkin wrote:
>>>>
>>>>> Hi Gabo
>>>>>
>>>>> It is an 'Object' so a WSDL generator has no idea what else to say,
>>>>> apart
>>>>> from <representation/>. If you add "Consumes' with some values then
>>>>> you'll
>>>>> get a bit more specific tag...
>>>>>
>>>>>
>>>>> However, there appears to be a bug :
>>>>>
>>>>> <response><!-- Primitive type : xs:long
>>>>> --><representation
>>>>> mediaType="text/xml"/></response></method></resource>
>>>>>
>>>>> or do you have Produces('text/xml') on the class itself ? Can you
>>>>> please
>>>>> send me a class sample so that I can fix it ?
>>>>>
>>>>> cheers, Sergey
>>>>>
>>>>>
>>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>>
>>> No virus found in this incoming message.
>>> Checked by AVG - www.avg.com
>>> Version: 8.5.409 / Virus Database: 270.13.62/2315 - Release Date:
>>> 08/20/09 06:05:00
>>>
>>>
>>
>>
>
>
--
View this message in context: http://www.nabble.com/JAX-RS-%3A-initial-WADL-support-tp24394736p25115746.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: JAX-RS : initial WADL support
Posted by Sergey Beryozkin <se...@iona.com>.
Hi Gabo
MyObject has @XmlRootElement with only a local name specified. Does
package-info.java has a namespace specified too, in addition to the local
name ?
cheers, Sergey
Gabo Manuel wrote:
>
> Hi Sergey,
>
> I am a bit confused. How do I supply the namespace needed? I thought the
> package-info.java would be enough.
>
> Yes, for now I would be limiting the consume to just text/xml. The
> initial intent was to take advantage of CXF's handling between xml and
> json. But for now, we would be sticking to text/xml.
>
> Gabo
>
> Sergey Beryozkin wrote:
>> Hi Gabo
>>
>> thanks...
>> The reason you only see the '<representation/>' for my MyObject is that
>> there's no namespace available , so even though the <grammars/> section
>> has
>> the schema embedded there's no way to link to it from the
>> <representation/>.
>> May be I should have some XML comment generated which will advise to
>> check
>> the schema (with no namespace) ?
>>
>> You might also want to update Consumes("*/*") to require a more specific
>> media type.
>>
>>
>>> I haven't tried it lately without the providers, but are primitives now
>>> supported out of the box?
>>>
>>
>> They are but only for text/plain. I'll add a task to wrap them in some
>> tag
>> like <response> for xml media types
>>
>>
>>> Also, is there somewhere to look to be able to use the tool that creates
>>> an http-centric client-code from the wadl?
>>>
>>
>> No, I haven't started working on the code gen tool yet....But it's on the
>> map
>>
>> cheers, Sergey
>>
>>
>>
>> Gabo Manuel wrote:
>>
>>> Hi Sergey,
>>>
>>> Sorry for the late response. I may have misrepresented the method, it
>>> should be as follows:
>>>
>>> @WebService(name="MyObjectService")
>>> @SOAPBinding(use=Use.LITERAL, style=Style.RPC)
>>> @Consumes("*/*")
>>> @Produces("text/xml")
>>> @Path("/MyObjects")
>>> public interface MyObjectService{
>>> @GET
>>> @Path("/")
>>> @WebMethod
>>> @WebResult(name="myObjectInstance")
>>> public MyObject getMyObject(
>>> @QueryParam("uniqueIDField")
>>> @WebParam(name="uniqueIDField")
>>> long uniqueIDField)
>>> ;
>>>
>>> @PUT
>>> @Path("/")
>>> @WebMethod
>>> @WebResult(name="uniqueIDField")
>>> public long insertMyObject(
>>> @WebParam(name="myObjectInstance")
>>> MyObject myObjectInstance,
>>> @QueryParam("reason")
>>> @WebParam(name="reason")
>>> String reason
>>> )
>>> ;
>>> }
>>>
>>> @WebService(endpointInterface="some.domain.MyObjectService",
>>> serviceName="MyObjectService", portName="MyObjectServicePort")
>>> public class MyObjectServiceImpl implements MyObjectService{
>>> public MyObject getMyObject(long uniqueIDField) throws
>>> SolegyContingencyException{
>>> return new MyObject();
>>> }
>>> public long insertMyObject(MyObject myObjectInstance, String reason)
>>> throws SolegyContingencyException{
>>> return 1;
>>> }
>>> }
>>>
>>> @XmlType(name="MyObject")
>>> @XmlAccessorType(XmlAccessType.PROPERTY)
>>> @XmlRootElement(name="MyObject")
>>> public class MyObject {
>>> private long uniqueIDField;
>>> @GET
>>> @Path("/uniqueIDField")
>>> public long getUniqueIDField() {
>>> return uniqueIDField;
>>> }
>>> public void setUniqueIDField(long uniqueIDField) {
>>> this.uniqueIDField = uniqueIDField;
>>> }
>>> }
>>>
>>> The wadl section i get is something as follows:
>>>
>>> <method name="GET">
>>> <request>
>>>
>>> </request>
>>> <response>
>>> <representation mediaType="text/xml"/>
>>> </response>
>>> </method>
>>> <method name="PUT">
>>> <request>
>>> <representation/>
>>>
>>> </request>
>>> <response>
>>> <!-- Primitive type : xs:long --><representation
>>> mediaType="text/xml"/>
>>> </response>
>>> </method>
>>>
>>> And yes, I did specify text/xml. I also have providers included to wrap
>>> the response in tags. I had to add the providers because at the time
>>> (2.0), primitives were not supported. I haven't tried it lately without
>>> the providers, but are primitives now supported out of the box?
>>>
>>> Also, is there somewhere to look to be able to use the tool that creates
>>> an http-centric client-code from the wadl?
>>>
>>> Thanks!
>>>
>>> Gabo.
>>>
>>> Sergey Beryozkin wrote:
>>>
>>>> Hi Gabo
>>>>
>>>> It is an 'Object' so a WSDL generator has no idea what else to say,
>>>> apart
>>>> from <representation/>. If you add "Consumes' with some values then
>>>> you'll
>>>> get a bit more specific tag...
>>>>
>>>>
>>>> However, there appears to be a bug :
>>>>
>>>> <response><!-- Primitive type : xs:long
>>>> --><representation
>>>> mediaType="text/xml"/></response></method></resource>
>>>>
>>>> or do you have Produces('text/xml') on the class itself ? Can you
>>>> please
>>>> send me a class sample so that I can fix it ?
>>>>
>>>> cheers, Sergey
>>>>
>>>>
>>>
>>
>>
>> ------------------------------------------------------------------------
>>
>>
>> No virus found in this incoming message.
>> Checked by AVG - www.avg.com
>> Version: 8.5.409 / Virus Database: 270.13.62/2315 - Release Date:
>> 08/20/09 06:05:00
>>
>>
>
>
--
View this message in context: http://www.nabble.com/JAX-RS-%3A-initial-WADL-support-tp24394736p25062023.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: JAX-RS : initial WADL support
Posted by Gabo Manuel <km...@solegysystems.com>.
Hi Sergey,
I am a bit confused. How do I supply the namespace needed? I thought the
package-info.java would be enough.
Yes, for now I would be limiting the consume to just text/xml. The
initial intent was to take advantage of CXF's handling between xml and
json. But for now, we would be sticking to text/xml.
Gabo
Sergey Beryozkin wrote:
> Hi Gabo
>
> thanks...
> The reason you only see the '<representation/>' for my MyObject is that
> there's no namespace available , so even though the <grammars/> section has
> the schema embedded there's no way to link to it from the <representation/>.
> May be I should have some XML comment generated which will advise to check
> the schema (with no namespace) ?
>
> You might also want to update Consumes("*/*") to require a more specific
> media type.
>
>
>> I haven't tried it lately without the providers, but are primitives now
>> supported out of the box?
>>
>
> They are but only for text/plain. I'll add a task to wrap them in some tag
> like <response> for xml media types
>
>
>> Also, is there somewhere to look to be able to use the tool that creates
>> an http-centric client-code from the wadl?
>>
>
> No, I haven't started working on the code gen tool yet....But it's on the
> map
>
> cheers, Sergey
>
>
>
> Gabo Manuel wrote:
>
>> Hi Sergey,
>>
>> Sorry for the late response. I may have misrepresented the method, it
>> should be as follows:
>>
>> @WebService(name="MyObjectService")
>> @SOAPBinding(use=Use.LITERAL, style=Style.RPC)
>> @Consumes("*/*")
>> @Produces("text/xml")
>> @Path("/MyObjects")
>> public interface MyObjectService{
>> @GET
>> @Path("/")
>> @WebMethod
>> @WebResult(name="myObjectInstance")
>> public MyObject getMyObject(
>> @QueryParam("uniqueIDField")
>> @WebParam(name="uniqueIDField")
>> long uniqueIDField)
>> ;
>>
>> @PUT
>> @Path("/")
>> @WebMethod
>> @WebResult(name="uniqueIDField")
>> public long insertMyObject(
>> @WebParam(name="myObjectInstance")
>> MyObject myObjectInstance,
>> @QueryParam("reason")
>> @WebParam(name="reason")
>> String reason
>> )
>> ;
>> }
>>
>> @WebService(endpointInterface="some.domain.MyObjectService",
>> serviceName="MyObjectService", portName="MyObjectServicePort")
>> public class MyObjectServiceImpl implements MyObjectService{
>> public MyObject getMyObject(long uniqueIDField) throws
>> SolegyContingencyException{
>> return new MyObject();
>> }
>> public long insertMyObject(MyObject myObjectInstance, String reason)
>> throws SolegyContingencyException{
>> return 1;
>> }
>> }
>>
>> @XmlType(name="MyObject")
>> @XmlAccessorType(XmlAccessType.PROPERTY)
>> @XmlRootElement(name="MyObject")
>> public class MyObject {
>> private long uniqueIDField;
>> @GET
>> @Path("/uniqueIDField")
>> public long getUniqueIDField() {
>> return uniqueIDField;
>> }
>> public void setUniqueIDField(long uniqueIDField) {
>> this.uniqueIDField = uniqueIDField;
>> }
>> }
>>
>> The wadl section i get is something as follows:
>>
>> <method name="GET">
>> <request>
>>
>> </request>
>> <response>
>> <representation mediaType="text/xml"/>
>> </response>
>> </method>
>> <method name="PUT">
>> <request>
>> <representation/>
>>
>> </request>
>> <response>
>> <!-- Primitive type : xs:long --><representation
>> mediaType="text/xml"/>
>> </response>
>> </method>
>>
>> And yes, I did specify text/xml. I also have providers included to wrap
>> the response in tags. I had to add the providers because at the time
>> (2.0), primitives were not supported. I haven't tried it lately without
>> the providers, but are primitives now supported out of the box?
>>
>> Also, is there somewhere to look to be able to use the tool that creates
>> an http-centric client-code from the wadl?
>>
>> Thanks!
>>
>> Gabo.
>>
>> Sergey Beryozkin wrote:
>>
>>> Hi Gabo
>>>
>>> It is an 'Object' so a WSDL generator has no idea what else to say, apart
>>> from <representation/>. If you add "Consumes' with some values then
>>> you'll
>>> get a bit more specific tag...
>>>
>>>
>>> However, there appears to be a bug :
>>>
>>> <response><!-- Primitive type : xs:long
>>> --><representation mediaType="text/xml"/></response></method></resource>
>>>
>>> or do you have Produces('text/xml') on the class itself ? Can you please
>>> send me a class sample so that I can fix it ?
>>>
>>> cheers, Sergey
>>>
>>>
>>
>
>
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.409 / Virus Database: 270.13.62/2315 - Release Date: 08/20/09 06:05:00
>
>
Re: JAX-RS : initial WADL support
Posted by Sergey Beryozkin <se...@iona.com>.
Hi Gabo
thanks...
The reason you only see the '<representation/>' for my MyObject is that
there's no namespace available , so even though the <grammars/> section has
the schema embedded there's no way to link to it from the <representation/>.
May be I should have some XML comment generated which will advise to check
the schema (with no namespace) ?
You might also want to update Consumes("*/*") to require a more specific
media type.
> I haven't tried it lately without the providers, but are primitives now
> supported out of the box?
They are but only for text/plain. I'll add a task to wrap them in some tag
like <response> for xml media types
> Also, is there somewhere to look to be able to use the tool that creates
> an http-centric client-code from the wadl?
No, I haven't started working on the code gen tool yet....But it's on the
map
cheers, Sergey
Gabo Manuel wrote:
>
> Hi Sergey,
>
> Sorry for the late response. I may have misrepresented the method, it
> should be as follows:
>
> @WebService(name="MyObjectService")
> @SOAPBinding(use=Use.LITERAL, style=Style.RPC)
> @Consumes("*/*")
> @Produces("text/xml")
> @Path("/MyObjects")
> public interface MyObjectService{
> @GET
> @Path("/")
> @WebMethod
> @WebResult(name="myObjectInstance")
> public MyObject getMyObject(
> @QueryParam("uniqueIDField")
> @WebParam(name="uniqueIDField")
> long uniqueIDField)
> ;
>
> @PUT
> @Path("/")
> @WebMethod
> @WebResult(name="uniqueIDField")
> public long insertMyObject(
> @WebParam(name="myObjectInstance")
> MyObject myObjectInstance,
> @QueryParam("reason")
> @WebParam(name="reason")
> String reason
> )
> ;
> }
>
> @WebService(endpointInterface="some.domain.MyObjectService",
> serviceName="MyObjectService", portName="MyObjectServicePort")
> public class MyObjectServiceImpl implements MyObjectService{
> public MyObject getMyObject(long uniqueIDField) throws
> SolegyContingencyException{
> return new MyObject();
> }
> public long insertMyObject(MyObject myObjectInstance, String reason)
> throws SolegyContingencyException{
> return 1;
> }
> }
>
> @XmlType(name="MyObject")
> @XmlAccessorType(XmlAccessType.PROPERTY)
> @XmlRootElement(name="MyObject")
> public class MyObject {
> private long uniqueIDField;
> @GET
> @Path("/uniqueIDField")
> public long getUniqueIDField() {
> return uniqueIDField;
> }
> public void setUniqueIDField(long uniqueIDField) {
> this.uniqueIDField = uniqueIDField;
> }
> }
>
> The wadl section i get is something as follows:
>
> <method name="GET">
> <request>
>
> </request>
> <response>
> <representation mediaType="text/xml"/>
> </response>
> </method>
> <method name="PUT">
> <request>
> <representation/>
>
> </request>
> <response>
> <!-- Primitive type : xs:long --><representation
> mediaType="text/xml"/>
> </response>
> </method>
>
> And yes, I did specify text/xml. I also have providers included to wrap
> the response in tags. I had to add the providers because at the time
> (2.0), primitives were not supported. I haven't tried it lately without
> the providers, but are primitives now supported out of the box?
>
> Also, is there somewhere to look to be able to use the tool that creates
> an http-centric client-code from the wadl?
>
> Thanks!
>
> Gabo.
>
> Sergey Beryozkin wrote:
>> Hi Gabo
>>
>> It is an 'Object' so a WSDL generator has no idea what else to say, apart
>> from <representation/>. If you add "Consumes' with some values then
>> you'll
>> get a bit more specific tag...
>>
>>
>> However, there appears to be a bug :
>>
>> <response><!-- Primitive type : xs:long
>> --><representation mediaType="text/xml"/></response></method></resource>
>>
>> or do you have Produces('text/xml') on the class itself ? Can you please
>> send me a class sample so that I can fix it ?
>>
>> cheers, Sergey
>>
>
>
--
View this message in context: http://www.nabble.com/JAX-RS-%3A-initial-WADL-support-tp24394736p25060698.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: JAX-RS : initial WADL support
Posted by Gabo Manuel <km...@solegysystems.com>.
Hi Sergey,
Sorry for the late response. I may have misrepresented the method, it
should be as follows:
@WebService(name="MyObjectService")
@SOAPBinding(use=Use.LITERAL, style=Style.RPC)
@Consumes("*/*")
@Produces("text/xml")
@Path("/MyObjects")
public interface MyObjectService{
@GET
@Path("/")
@WebMethod
@WebResult(name="myObjectInstance")
public MyObject getMyObject(
@QueryParam("uniqueIDField")
@WebParam(name="uniqueIDField")
long uniqueIDField)
;
@PUT
@Path("/")
@WebMethod
@WebResult(name="uniqueIDField")
public long insertMyObject(
@WebParam(name="myObjectInstance")
MyObject myObjectInstance,
@QueryParam("reason")
@WebParam(name="reason")
String reason
)
;
}
@WebService(endpointInterface="some.domain.MyObjectService",
serviceName="MyObjectService", portName="MyObjectServicePort")
public class MyObjectServiceImpl implements MyObjectService{
public MyObject getMyObject(long uniqueIDField) throws
SolegyContingencyException{
return new MyObject();
}
public long insertMyObject(MyObject myObjectInstance, String reason)
throws SolegyContingencyException{
return 1;
}
}
@XmlType(name="MyObject")
@XmlAccessorType(XmlAccessType.PROPERTY)
@XmlRootElement(name="MyObject")
public class MyObject {
private long uniqueIDField;
@GET
@Path("/uniqueIDField")
public long getUniqueIDField() {
return uniqueIDField;
}
public void setUniqueIDField(long uniqueIDField) {
this.uniqueIDField = uniqueIDField;
}
}
The wadl section i get is something as follows:
<method name="GET">
<request>
<param name="uniqueIDField" style="query" type="xs:long"/>
</request>
<response>
<representation mediaType="text/xml"/>
</response>
</method>
<method name="PUT">
<request>
<representation/>
<param name="reason" style="query" type="xs:string"/>
</request>
<response>
<!-- Primitive type : xs:long --><representation mediaType="text/xml"/>
</response>
</method>
And yes, I did specify text/xml. I also have providers included to wrap
the response in tags. I had to add the providers because at the time
(2.0), primitives were not supported. I haven't tried it lately without
the providers, but are primitives now supported out of the box?
Also, is there somewhere to look to be able to use the tool that creates
an http-centric client-code from the wadl?
Thanks!
Gabo.
Sergey Beryozkin wrote:
> Hi Gabo
>
> It is an 'Object' so a WSDL generator has no idea what else to say, apart
> from <representation/>. If you add "Consumes' with some values then you'll
> get a bit more specific tag...
>
>
> However, there appears to be a bug :
>
> <response><!-- Primitive type : xs:long
> --><representation mediaType="text/xml"/></response></method></resource>
>
> or do you have Produces('text/xml') on the class itself ? Can you please
> send me a class sample so that I can fix it ?
>
> cheers, Sergey
>
Re: JAX-RS : initial WADL support
Posted by Sergey Beryozkin <se...@iona.com>.
Hi Gabo
It is an 'Object' so a WSDL generator has no idea what else to say, apart
from <representation/>. If you add "Consumes' with some values then you'll
get a bit more specific tag...
However, there appears to be a bug :
<response><!-- Primitive type : xs:long
--><representation mediaType="text/xml"/></response></method></resource>
or do you have Produces('text/xml') on the class itself ? Can you please
send me a class sample so that I can fix it ?
cheers, Sergey
Gabo Manuel wrote:
>
> Hi Sergey,
>
> By looking at the generated WADL, how does one tell if there is an
> expected payload with the method involved. If I have the following
> annotated method:
>
> @PUT
> @Path("/somepath/")
> @WebMethod
> @WebResult(name="result")
> public long insert(
> Object ap,
> @QueryParam("transactionDescription")
> String transactionDescription
> )
>
> The wadl generated is as follows:
> <resource path="/somepath/"><method
> name="PUT"><request><representation/></request><response><!-- Primitive
> type : xs:long
> --><representation mediaType="text/xml"/></response></method></resource>
>
> I am assuming the "<representation/>" is what should hint at it, but by
> just looking at the wadl, I am not able to tell which of the complexType
> described above in the wadl is to be used. Maybe replacing/modifying it
> to contain the name of the complexType would help.
>
> I could be missing something from the user's guide. Please advise.
>
> Thanks in advance.
>
> Gabo
>
>
> Sergey Beryozkin wrote:
>> Hi,
>>
>> I'm not seeing an immediate need in it as I don't see what we actually
>> can do with this tool (I would actually prefer not to add 'wadl' in
>> the name of such would-be tool, rather I would have a single tool
>> capable of supporting multiple document types if needed).
>>
>> As I said before, the only thing we can do with WADL is to generate
>> client-side HTTP-centric code. But no typed server Java code.
>> It may also may not be obvious what sort of http-centric code we can
>> generate given that at the WebClient level the notion of 'subresource'
>> is really non-existent, for ex :
>>
>> WebClient client = WebClient.create(http://bar);
>>
>> client.path("/foo/baz").get();
>> client.path("/foo").path("baz").get();
>>
>> are two identical lines really. It's a server-side issue if /baz
>> should be handled by a subresource object or not.
>>
>> At the moment I can see how UI tool, possibly a web-based one would
>> utilize WADLs for testing/visualizing, but I'm not sure yet what we
>> would do with WADL at the code gen level, unless we introduce some
>> CXF-specifc wadl extensions....
>>
>> cheers, Sergey
>>
>
>
--
View this message in context: http://www.nabble.com/JAX-RS-%3A-initial-WADL-support-tp24394736p24970669.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: JAX-RS : initial WADL support
Posted by Gabo Manuel <km...@solegysystems.com>.
Hi Sadhana,
Any chance that an out interceptor is enclosing the result? I think the
generation of wadl is still treated as a regular transaction so all in
and out interceptor chains apply.
Gabo
Sadhana Jain wrote:
> Hi Sergey,
>
> Thanks for the WADL generation support in CXF JAX-RS implementation.
> I tried it and it looks good. I was wondering why the WADL is generated within <String>...</String> elements? Is there a way to not get these and get only the valid WADL?
>
> Thanks,
> Sadhana
>
> Sadhana Jain
> Sr. Software Engineer
>
>
> Rovi Corporation
> 795 Folsom St, Suite 200
> San Francisco, CA 94107
> Direct: 415.247.5023 | Mobile: 925.212.6495
> sadhana.jain@rovicorp.com
> rovicorp.com
>
>
> Rovi. The new name for Macrovision.
>
>
> -----Original Message-----
> From: Sergey Beryozkin [mailto:sberyozk@progress.com]
> Sent: Wednesday, July 08, 2009 9:23 AM
> To: users@cxf.apache.org
> Subject: JAX-RS : initial WADL support
>
> 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
> ------------------------------------------------------------------------
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.409 / Virus Database: 270.13.66/2325 - Release Date: 08/25/09 06:08:00
>
>
RE: JAX-RS : initial WADL support
Posted by Sadhana Jain <Sa...@rovicorp.com>.
Hi Sergey,
Thanks for the WADL generation support in CXF JAX-RS implementation.
I tried it and it looks good. I was wondering why the WADL is generated within <String>...</String> elements? Is there a way to not get these and get only the valid WADL?
Thanks,
Sadhana
Sadhana Jain
Sr. Software Engineer
Rovi Corporation
795 Folsom St, Suite 200
San Francisco, CA 94107
Direct: 415.247.5023 | Mobile: 925.212.6495
sadhana.jain@rovicorp.com
rovicorp.com
Rovi. The new name for Macrovision.
-----Original Message-----
From: Sergey Beryozkin [mailto:sberyozk@progress.com]
Sent: Wednesday, July 08, 2009 9:23 AM
To: users@cxf.apache.org
Subject: JAX-RS : initial WADL support
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