You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Gabo Manuel <km...@solegysystems.com> on 2009/08/07 08:39:39 UTC

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@cxf.apache.org
> 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
>
>   

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 Gabo Manuel <km...@solegysystems.com>.
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

RE: JAX-RS : initial WADL support

Posted by Sergey Beryozkin <sb...@progress.com>.
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@solegysystems.com]
Sent: Fri 8/7/2009 2:39 AM
To: users@cxf.apache.org
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@cxf.apache.org
> 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
>
>