One more thing - I had to move the super.initiate down below my
explicit root resources initialization. i can imagine that will trip
some people up. Is there a more correct way to initialize these
resources?
public class MyServletContainer extends ServletContainer {
@Override
public void initiate(ResourceConfig rc, WebApplication wa) {
rc.getExplicitRootResources().put("widget/{custom}",
GenericViewResource.class);
rc.getExplicitRootResources().put("people/{custom}/{custom2}",
GenericViewResource.class);
super.initiate(rc, wa);
}
Thanks again for the enhancement!
On Fri, Aug 7, 2009 at 1:10 PM, Adam Rabung<adamrabung_at_gmail.com> wrote:
> 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
>>
>>
>