 | Start a set with this search |
 | Include this search in one of my sets |
 | Exclude this search from one of my sets |
 | Permalink to these results Paste this link in email or IM: |
 | Atom feed for tracking future search results Paste this URL into your reader: |
9 messages in net.java.dev.jersey.usersRe: [Jersey] [PATCH] to allow the API...| From | Sent On | Attachments |
|---|---|---|
| James Strachan | Feb 19, 2009 7:03 am | |
| Paul Sandoz | Feb 19, 2009 7:13 am | |
| James Strachan | Feb 19, 2009 7:41 am | |
| Paul Sandoz | Feb 20, 2009 6:01 am | |
| James Strachan | Feb 20, 2009 6:38 am | |
| Paul Sandoz | Feb 20, 2009 8:40 am | |
| Paul Sandoz | Feb 24, 2009 2:53 am | |
| James Strachan | Feb 24, 2009 10:18 am | |
| Paul Sandoz | Feb 25, 2009 12:03 am |
| Permalink for this message Paste this link in email or IM: |
| Permalink for this thread Paste this link in email or IM: |
| Atom feed for this thread Paste this URL into your reader: |
| Subject: | Re: [Jersey] [PATCH] to allow the API of RESTful services to be rendered using hierarchial Implicit Views | Actions... |
|---|---|---|
| From: | James Strachan (jame...@gmail.com) | |
| Date: | Feb 24, 2009 10:18:05 am | |
| List: | net.java.dev.jersey.users | |
2009/2/24 Paul Sandoz <Paul...@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/@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/