> I'm confused, let me play back the requirements to check if I
> understand correctly:
>
> You want the same class Bar to be called for both:
>
> /foo/bar/baz
> /foo/bar
>
> Right ?
I'm sorry, I just mistyped my example twice.
I want my subresource class to serve both requests, with /foo taken care of by a root class :
/foo/bar/baz
/foo/bar
they may or may not return Bar in both cases. Probably not.
>
> If so then why not:
>
> // root resource
> @Path("foo")
> public class Foo {
>
> @Path("bar")
> public Bar getBar() {...}
>
> @Path("bar/baz")
> public Bar getBarAsWell() {...}
> }
>
> // not a root resource
> public class Bar {
>
> @GET
> String get() {...}
> }
I agree it works in this case.
Still, using @Path as a designator for root resources is somewhat restricting IMHO.
As you demonstrate, one can make things work by expanding the root resource class as needed, same for subresources for applications with deeper hierarchies.
But I think I agree with Bill suggesting to introduce a specific designator for root resources. That way, runtimes can still smartly pick up root classes from a classpath and @Path will be usable in a more flexible way, with defaults for root classes (clashes will be detected same way they can be detected for explicit @Path values ), etc, with @Paths being on subresources without making them root resources, etc...
Thanks, Sergey
>
> Marc.
>
> ---
> Marc Hadley <marc.hadley at sun.com>
> CTO Office, Sun Microsystems.
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland