This is working great - I think I am good to go with respect to
generic Resources. Thanks for extremely quick turnaround!
Adam
On Fri, Aug 7, 2009 at 9:13 AM, Paul Sandoz<Paul.Sandoz_at_sun.com> wrote:
> 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
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net
>
>