On Tue, 2008-06-10 at 11:01 -0400, Marc Hadley wrote:
> On Jun 10, 2008, at 10:53 AM, Martin Grotzke wrote:
> >>>
> >> I was going to suggest the same, that would at least give some
> >> baseline information.
> > Hmm, I don't really get what you have in mind. What does "additional
> > URI
> > space" actually mean?
> >
> A returned instance of a subclass of the declared type might have
> additional resource methods or locators not present on the base class.
Ok, now it found the way into my mind, thanx :)
I would suggest to first support the most common use case - IMHO this is
a concrete class that is returned from a sub-resource locator without
thinking about possibly existing subclasses. This would make lots of
users happy.
Cheers,
Martin
>
> E.g. the subresource locator might have a declared return type of
> UserResource but actually return a SuperUserResource (extends
> UserResource) that has extra capabilities.
>
> Marc.
>
> > To me it looks like this:
> > - we have a root resource UsersResource with @Path("/users")
> > - this has a sub-resource locator "UsersResource.getUser" with
> > @Path("{username}") that returns a UserResource
> > - The UserResource has the path "{username}" as context and several
> > resource methods (UserResource.getUser, UserResource.updateUser
> > etc.), sub-resource methods and sub-resource locators.
> >
> > So the UserResource has the context path "/users/{username}" and all
> > resource methods, sub-resource methods and sub-resource locators of
> > the
> > UserResource are related to this path.
> >
> > I'd say we have all information that we need.
> >
> > Why do we not know, what concrete resource classes are returned from a
> > sub-resource locator? UserResource is the return type of the
> > sub-resource locator and seems very concrete to me :)
> >
> > What is the actual problem then? Probably I'm missing s.th. :)
> >
> > Cheers,
> > Martin
> >
> >
> >>
> >> Marc.
> >>
> >> ---
> >> Marc Hadley <marc.hadley at sun.com>
> >> CTO Office, Sun Microsystems.
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> >> For additional commands, e-mail: users-help_at_jersey.dev.java.net
> >
>
> ---
> Marc Hadley <marc.hadley at sun.com>
> CTO Office, Sun Microsystems.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jersey.dev.java.net
> For additional commands, e-mail: users-help_at_jersey.dev.java.net