Hi Marc,
On Tue, 2008-06-10 at 12:45 -0400, Marc Hadley wrote:
> On Jun 10, 2008, at 12:39 PM, Martin Grotzke wrote:
> >
> > 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.
>
> +1
Cool :)
Though Paul and other devs didn't vote until now I want to ask if you
can have a look at the WadlGenerator as I tried to achieve exactly this,
but unfortunately without success [1] ;)
Thanx in advance,
cheers,
Martin
[1]
https://jersey.dev.java.net/servlets/ReadMsg?listName=users&msgNo=1555
>
> Marc.
>
> >
> >>
> >> 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
> >
>
> ---
> 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