JAX-RS : initial WADL support

[Sergey Beryozkin-2]

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

[Sergey Beryozkin-2]

Some more info.

Going to the service listings page is not the only way to see the wadl instances, generally one can get it using a ?_wadl query
(note that the queries supported natively by the jax-rs runtime are prefixed with '_').

For ex, given

Base address : 'http://localhost:8080'
WAR name : 'store'
CXFServlet : '/books/*'
jaxrs:server/@address = '/orders'
jaxrs:server/@enableStaticResoulution = 'true'

and 2 root resource classes registered with this endpoint, say @Path("/fiction") FictionBookOrders and @Path("/sport")
SportBookOrders, then

http://localhost:8080/store/books/orders?_wadl

will give you the description of all the root resource classes registered with a given jaxrs:server endpoint, including all the
subresources. While

http://localhost:8080/store/books/orders/fiction?_wadl
http://localhost:8080/store/books/orders/sport?_wadl

will give you all the info for FictionBookOrders &  SportBookOrders respectively.

If you have many jaxrs:endpoints then visiting http://localhost:8080/store/books or http://localhost:8080/store/books/services will
let you see all the wadl links.

Note that the media type for a ?_wadl response is set to 'application/vnd.sun.wadl+xml' which is something Firefox does not really
like unless some wadl plugin is registered. If Accept is set to 'application/xml' then Firefox will show it with no problems. Doing
?_wadl&_type=xml will ensure Accept is set to 'application/xml'.

cheers, Sergey





----- Original Message -----
From: Sergey Beryozkin
To: users@...
Sent: Wednesday, July 08, 2009 5:23 PM
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

[Nathaniel Auvil]

Sergey,

Is the intent to have a WADL2JAX-RS capability?



On Thu, Jul 9, 2009 at 5:32 AM, Sergey Beryozkin <sberyozk@...>wrote:

> Some more info.
>
> Going to the service listings page is not the only way to see the wadl
> instances, generally one can get it using a ?_wadl query (note that the
> queries supported natively by the jax-rs runtime are prefixed with '_').
>
> For ex, given
>
> Base address : 'http://localhost:8080'
> WAR name : 'store'
> CXFServlet : '/books/*'
> jaxrs:server/@address = '/orders'
> jaxrs:server/@enableStaticResoulution = 'true'
>
> and 2 root resource classes registered with this endpoint, say
> @Path("/fiction") FictionBookOrders and @Path("/sport") SportBookOrders,
> then
>
> http://localhost:8080/store/books/orders?_wadl
>
> will give you the description of all the root resource classes registered
> with a given jaxrs:server endpoint, including all the subresources. While
>
> http://localhost:8080/store/books/orders/fiction?_wadl
> http://localhost:8080/store/books/orders/sport?_wadl
>
> will give you all the info for FictionBookOrders &  SportBookOrders
> respectively.
>
> If you have many jaxrs:endpoints then visiting
> http://localhost:8080/store/books or
> http://localhost:8080/store/books/services will let you see all the wadl
> links.
>
> Note that the media type for a ?_wadl response is set to
> 'application/vnd.sun.wadl+xml' which is something Firefox does not really
> like unless some wadl plugin is registered. If Accept is set to
> 'application/xml' then Firefox will show it with no problems. Doing
> ?_wadl&_type=xml will ensure Accept is set to 'application/xml'.
>
> cheers, Sergey
>
>
>
>
>
> ----- Original Message ----- From: Sergey Beryozkin
> To: users@...
> Sent: Wednesday, July 08, 2009 5:23 PM
> 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
>

[Sergey Beryozkin-2]

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

> Sergey,
>
> Is the intent to have a WADL2JAX-RS capability?
>
>
>
> On Thu, Jul 9, 2009 at 5:32 AM, Sergey Beryozkin <sberyozk@...>wrote:
>
>> Some more info.
>>
>> Going to the service listings page is not the only way to see the wadl
>> instances, generally one can get it using a ?_wadl query (note that the
>> queries supported natively by the jax-rs runtime are prefixed with '_').
>>
>> For ex, given
>>
>> Base address : 'http://localhost:8080'
>> WAR name : 'store'
>> CXFServlet : '/books/*'
>> jaxrs:server/@address = '/orders'
>> jaxrs:server/@enableStaticResoulution = 'true'
>>
>> and 2 root resource classes registered with this endpoint, say
>> @Path("/fiction") FictionBookOrders and @Path("/sport") SportBookOrders,
>> then
>>
>> http://localhost:8080/store/books/orders?_wadl
>>
>> will give you the description of all the root resource classes registered
>> with a given jaxrs:server endpoint, including all the subresources. While
>>
>> http://localhost:8080/store/books/orders/fiction?_wadl
>> http://localhost:8080/store/books/orders/sport?_wadl
>>
>> will give you all the info for FictionBookOrders &  SportBookOrders
>> respectively.
>>
>> If you have many jaxrs:endpoints then visiting
>> http://localhost:8080/store/books or
>> http://localhost:8080/store/books/services will let you see all the wadl
>> links.
>>
>> Note that the media type for a ?_wadl response is set to
>> 'application/vnd.sun.wadl+xml' which is something Firefox does not really
>> like unless some wadl plugin is registered. If Accept is set to
>> 'application/xml' then Firefox will show it with no problems. Doing
>> ?_wadl&_type=xml will ensure Accept is set to 'application/xml'.
>>
>> cheers, Sergey
>>
>>
>>
>>
>>
>> ----- Original Message ----- From: Sergey Beryozkin
>> To: users@...
>> Sent: Wednesday, July 08, 2009 5:23 PM
>> 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
>>
>

[Sergey Beryozkin-2]

> 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).

Actually, I think we're in position now to start working on a *single* code gen tool which will offer users options to generate the
server code or http-centric or proxy centric client code. WADL alone can help with the http-related client one. WADL with
cxf-extensions will do everything. In addition the user model info can also be used to satisfy all the tasks and may be used to add
cxf extensions to WADL. We might also get the WSDL2 in. So we're on the right track...The only thing that at the moment I can't
commit to any concrete dates....

Cheers, Sergey

>
> 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
>
>> Sergey,
>>
>> Is the intent to have a WADL2JAX-RS capability?
>>
>>
>>
>> On Thu, Jul 9, 2009 at 5:32 AM, Sergey Beryozkin <sberyozk@...>wrote:
>>
>>> Some more info.
>>>
>>> Going to the service listings page is not the only way to see the wadl
>>> instances, generally one can get it using a ?_wadl query (note that the
>>> queries supported natively by the jax-rs runtime are prefixed with '_').
>>>
>>> For ex, given
>>>
>>> Base address : 'http://localhost:8080'
>>> WAR name : 'store'
>>> CXFServlet : '/books/*'
>>> jaxrs:server/@address = '/orders'
>>> jaxrs:server/@enableStaticResoulution = 'true'
>>>
>>> and 2 root resource classes registered with this endpoint, say
>>> @Path("/fiction") FictionBookOrders and @Path("/sport") SportBookOrders,
>>> then
>>>
>>> http://localhost:8080/store/books/orders?_wadl
>>>
>>> will give you the description of all the root resource classes registered
>>> with a given jaxrs:server endpoint, including all the subresources. While
>>>
>>> http://localhost:8080/store/books/orders/fiction?_wadl
>>> http://localhost:8080/store/books/orders/sport?_wadl
>>>
>>> will give you all the info for FictionBookOrders &  SportBookOrders
>>> respectively.
>>>
>>> If you have many jaxrs:endpoints then visiting
>>> http://localhost:8080/store/books or
>>> http://localhost:8080/store/books/services will let you see all the wadl
>>> links.
>>>
>>> Note that the media type for a ?_wadl response is set to
>>> 'application/vnd.sun.wadl+xml' which is something Firefox does not really
>>> like unless some wadl plugin is registered. If Accept is set to
>>> 'application/xml' then Firefox will show it with no problems. Doing
>>> ?_wadl&_type=xml will ensure Accept is set to 'application/xml'.
>>>
>>> cheers, Sergey
>>>
>>>
>>>
>>>
>>>
>>> ----- Original Message ----- From: Sergey Beryozkin
>>> To: users@...
>>> Sent: Wednesday, July 08, 2009 5:23 PM
>>> 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
>>>
>>
>

[Gabo Manuel]

Hi Sergey,

Just tested the recent release 2.2.3. I was able to retrieve the
generated wadl using _wadl. Some comments:

1. The resources tags could use a new line after the closing tag for
readability. Just a nice to have.
2. Example:

Class 1 is annotated with @Path("/Service")
Class 2 is annotated does not have a @Path but with a method that has
@Path("/Service/operation")

Doing a /Service/?_wadl displays all operations under class 1. Since
they have the same start, I was thinking the said operation should have
been included in the wadl.

Doing a /?_wadl includes everything which is great!

Gabo

Sergey Beryozkin wrote:

> Some more info.
>
> Going to the service listings page is not the only way to see the wadl
> instances, generally one can get it using a ?_wadl query (note that
> the queries supported natively by the jax-rs runtime are prefixed with
> '_').
>
> For ex, given
>
> Base address : 'http://localhost:8080'
> WAR name : 'store'
> CXFServlet : '/books/*'
> jaxrs:server/@address = '/orders'
> jaxrs:server/@enableStaticResoulution = 'true'
>
> and 2 root resource classes registered with this endpoint, say
> @Path("/fiction") FictionBookOrders and @Path("/sport")
> SportBookOrders, then
>
> http://localhost:8080/store/books/orders?_wadl
>
> will give you the description of all the root resource classes
> registered with a given jaxrs:server endpoint, including all the
> subresources. While
>
> http://localhost:8080/store/books/orders/fiction?_wadl
> http://localhost:8080/store/books/orders/sport?_wadl
>
> will give you all the info for FictionBookOrders &  SportBookOrders
> respectively.
>
> If you have many jaxrs:endpoints then visiting
> http://localhost:8080/store/books or
> http://localhost:8080/store/books/services will let you see all the
> wadl links.
>
> Note that the media type for a ?_wadl response is set to
> 'application/vnd.sun.wadl+xml' which is something Firefox does not
> really like unless some wadl plugin is registered. If Accept is set to
> 'application/xml' then Firefox will show it with no problems. Doing
> ?_wadl&_type=xml will ensure Accept is set to 'application/xml'.
>
> cheers, Sergey
>
>
>
>
>
> ----- Original Message ----- From: Sergey Beryozkin
> To: users@...
> Sent: Wednesday, July 08, 2009 5:23 PM
> 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.375 / Virus Database: 270.13.8/2226 - Release Date: 07/08/09 21:51:00
>
>  

[Sergey Beryozkin-2]

Hi Gabo

thanks for your feedback.

> 1. The resources tags could use a new line after the closing tag for
> readability. Just a nice to have.

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.

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

/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...

cheers, Sergey

-----Original Message-----
From: Gabo Manuel [mailto:kmanuel@...]
Sent: Fri 8/7/2009 2:39 AM
To: users@...
Subject: Re: JAX-RS : initial WADL support
 
Hi Sergey,

Just tested the recent release 2.2.3. I was able to retrieve the
generated wadl using _wadl. Some comments:

1. The resources tags could use a new line after the closing tag for
readability. Just a nice to have.
2. Example:

Class 1 is annotated with @Path("/Service")
Class 2 is annotated does not have a @Path but with a method that has
@Path("/Service/operation")

Doing a /Service/?_wadl displays all operations under class 1. Since
they have the same start, I was thinking the said operation should have
been included in the wadl.

Doing a /?_wadl includes everything which is great!

Gabo

Sergey Beryozkin wrote:

> Some more info.
>
> Going to the service listings page is not the only way to see the wadl
> instances, generally one can get it using a ?_wadl query (note that
> the queries supported natively by the jax-rs runtime are prefixed with
> '_').
>
> For ex, given
>
> Base address : 'http://localhost:8080'
> WAR name : 'store'
> CXFServlet : '/books/*'
> jaxrs:server/@address = '/orders'
> jaxrs:server/@enableStaticResoulution = 'true'
>
> and 2 root resource classes registered with this endpoint, say
> @Path("/fiction") FictionBookOrders and @Path("/sport")
> SportBookOrders, then
>
> http://localhost:8080/store/books/orders?_wadl
>
> will give you the description of all the root resource classes
> registered with a given jaxrs:server endpoint, including all the
> subresources. While
>
> http://localhost:8080/store/books/orders/fiction?_wadl
> http://localhost:8080/store/books/orders/sport?_wadl
>
> will give you all the info for FictionBookOrders &  SportBookOrders
> respectively.
>
> If you have many jaxrs:endpoints then visiting
> http://localhost:8080/store/books or
> http://localhost:8080/store/books/services will let you see all the
> wadl links.
>
> Note that the media type for a ?_wadl response is set to
> 'application/vnd.sun.wadl+xml' which is something Firefox does not
> really like unless some wadl plugin is registered. If Accept is set to
> 'application/xml' then Firefox will show it with no problems. Doing
> ?_wadl&_type=xml will ensure Accept is set to 'application/xml'.
>
> cheers, Sergey
>
>
>
>
>
> ----- Original Message ----- From: Sergey Beryozkin
> To: users@...
> Sent: Wednesday, July 08, 2009 5:23 PM
> 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.375 / Virus Database: 270.13.8/2226 - Release Date: 07/08/09 21:51:00
>
>  

[Gabo Manuel]

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

[Sergey Beryozkin]

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

[Gabo Manuel]

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
>
>  

[Gabo Manuel]

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
>
>  

[Gabo Manuel]

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/><param
name="transactionDescription" style="query"
type="xs:string"/></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
>

[Sergey Beryozkin]

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
>

[Gabo Manuel]

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
>  

[Sergey Beryozkin]

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
>  

[Gabo Manuel]

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
>
>  

[Sergey Beryozkin]

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
>
>  

[Sergey Beryozkin]

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


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
>
>  

[Gabo Manuel]

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
>
>  

[Sergey Beryozkin-2]

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
>>
>>