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:[email protected]]
Sent: Fri 8/7/2009 2:39 AM
To: [email protected]
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: [email protected]
> 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
>
>
