2009/2/24 Paul Sandoz <Paul.Sandoz_at_sun.com>:
> Hi,
>
> The first part of the fix is in place.
>
> I have modified WadlResource to depend on the injection of
> WadlApplicationContext (see end of email):
>
> public WadlResource(@Context WadlApplicationContext wadlContext) {
> this.wadlContext = wadlContext;
> this.application = wadlContext.getApplication();
> }
>
> Thus it is now very easy to write your own WADL resource by injecting
> WadlApplicationContext and then connecting that resource to implicit views.
> For example:
>
>
> @Path("api")
> @ImplicitProduces("text/html;qs=5")
> @Produces({"application/vnd.sun.wadl+xml", "application/xml",
> "application/json"})
> public class MyWadlResource {
> @Context private WadlApplicationContext wadlContext;
>
> ...
> }
Great stuff :)
> Next steps:
>
> 1) investigate the move of WadlResource and creation of further classes into
> the API so that they can be
> extended. My initial thoughts on this is i want to be conservative in
> terms of implicit views, implicit produces
> and produces media types. i.e. the developer should override or replace
> as appropriate.
> Currently the patch for WadlResourceResource and WadlPartialResource are
> really specific to implicit
> views because there are not actual resource methods present. James, do
> you have any opinions on this?
I wonder if Jersey should ship with a default implementation of
WadlResource and WadlResourceResource (or whatever the 2 classes are
called - one for the application and one for sub resources) but by
default they are not mapped to anything (or maybe they are just mapped
to /application.wadl but then derived classes can map them to new URIs
with new @Produces/_at_ImplicitProduces?.
Then users can just derive from them and map them to a URI if they wish?
e.g.
@Path("api")
@ImplicitProduces("text/html;qs=5")
@Produces({"application/vnd.sun.wadl+xml", "application/xml",
"application/json"})
public class MyWadlResource extends WadlResource {
...
// not much code or inner knowledge of Jersey's impl required here
apart from the factory method to create nested resources...
protected WadlResourceResource createChildResource(String uri) {
return new MyWadlResourceResource(...);
}
}
Then the derived class is mostly about adding your own @Path /
@Produces and optional @ImplicitProduces and helper methods if you
need any? I'm keen for there to be as little ninja-Jersey hacking
required for folks to add the API stuff to their apps
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://fusesource.com/