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 <[email protected]>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
