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 <sbery...@progress.com>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
