users@jersey.java.net

Re: [Jersey] Dynamic _at_Path

From: Paul Sandoz <Paul.Sandoz_at_Sun.COM>
Date: Fri, 07 Aug 2009 15:13:49 +0200

Hi,

I have fixed this in the trunk. A SNAPSHOT build should make its way
to the repo in a couple of hours failing any java.net networking issues.

See ResourceConfig.getExplicitRootResources (javadoc below).

Paul.

     /**
      * Get a map of explicit root resource classes and root resource
singleton
      * instances. The default lifecycle for root resource class
instances is
      * per-request.
      * <p>
      * The root resource path template is declared using the key in
the map. This
      * is a substitute for the declaration of a {_at_link Path}
annotation on a root
      * resource class or singleton instance. The key has the same
semantics as the
      * {_at_link Path#value() }. If such a {_at_link Path} annotation is
present
      * it will be ignored.
      * <p>
      * For example, the following will register two root resources,
first
      * a root resource class at the path "class" and a root resource
singleton
      * at the path "singleton":
      * <blockquote><pre>
      * getExplicitRootResources().put("class",
RootResourceClass.class);
      * getExplicitRootResources().put("singleton", new
RootResourceSingleton());
      * </pre></blockquote>
      *
      * @return a map of explicit root resource classes and root
resource
      * singleton instances.
      */
     public Map<String, Object> getExplicitRootResources() {



On Aug 6, 2009, at 5:40 PM, Adam Rabung wrote:

> Hello,
> First off, I am loving Jersey! I'm finding it very intuitive and
> clean to write my resources/providers. Keep up the good work.
>
> My application has 5-10 "standard" rest resources that lend themselves
> well to the class/method annotation style of Jersey. However, several
> more resources are essentially defined externally. Think of these as
> XML reports which define the url they want to publish to:
> Report #1:
> <resource url = "/widgets/{widgetType}/widgetsInNeedOfRepair">
> .... DSL describing how to execute the query
> <resource>
>
> Report #2:
> <resource url =
> "/company/{company}/people/{department}/peopleWithExcessVacationTime?
> employeeType=manager">
> .... DSL describing how to execute the query
> <resource>
>
> These reports can be executed by the same generic Resource class, but
> many different Paths need to match this generic class. My goal is to
> allow this generic Resource to take advantage of other annotations
> (Produces, GET, etc) and all of the other Jersey resources such as
> Providers.
>
> I found a recommendation to use
> @Path("{fullPath}")
> I can then use UriInfo#getPathParameters to inspect what was passed in
> and glean out the path Parameters. I only have two problems w/ this
> approach:
> 1. As far as I can tell, I'd need a method for each number of
> anticipated path elements:
> @GET
> public Iterable<ExportNode> executeQuery1(@Context UriInfo ui) {
> return executeQuery(ui);
> }
>
> @GET
> @Path("/{param1}")
> public Iterable<ExportNode> executeQuery2(@Context UriInfo ui) {
> return executeQuery(ui);
> }
>
> @Path("/{param1}/{param2}")
> @GET
> public Iterable<ExportNode> executeQuery3(@Context UriInfo ui) {
> return executeQuery(ui);
> }
> etc etc
>
> 2. It seems this all-encompassing URL matching would cause problems
> for static file serving.
>
> I'm so new to Jersey and even Rest that I'm sure I'm taking a
> completely wrong approach here, but I think my "dream" code would be:
>
> ... at startup:
> jersey.registerResource("/widgets/{widgetType}/widgetsInNeedOfRepair",
> GenericResource.class);
> jersey.registerResource("/company/{company}/people/{department}/
> peopleWithExcessVacationTime?employeeType=manager",
> GenericResource.class);
> ...and Generic Resource:
> @Produces(javax.ws.rs.core.MediaType.APPLICATION_JSON)
> public class GenericResource {
> @GET
> public ReportResult executeQuery(@Context UriInfo ui) {
> //use UriInfo to figure out exactly which report they are invoking,
> and what the parameters are
> }
> }
>
> What's the right approach for a problem like this? Any input is much
> appreciated.
>
> Thanks,
> Adam
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>