Hi
>
> The ones with @Path on the class are root resources. Some may also be
> subresources (i.e. available via alternate URI paths) but that isn't
> an issue.
Ok. I understand now why resource classes are required to be annotated with @Path.
However, I don't see a spec that *all* resource classes annotated with @Path
be available as root resources. I actually find this requirement limiting the options available for real subresurces.
Lets assume I would like to have GET /foo/bar/baz requests served. And I really don't want /bar/baz requests served
along the way.
So I do :
@Path("/")
public class Foo {
@Path("/foo") public Bar getBar() { return bar};
}
public class Bar {
@GET
@Path("/bar/baz")
public String get() { return bar};
}
Suppose now I want Bar also serve /foo/bar requests :
public class Bar {
@Path("/bar")
public String get() { return bar};
@GET
@Path("/bar/baz")
public String get() { return bar};
}
Now I have two methods with @Path annotations and I really like to get rid of one of them :
@Path("/bar")
public class Bar {
public String get() { return bar};
@GET
@Path("/baz")
public String get() { return bar};
}
And I thought this is what I can do, and I actually can do it, but it will turn Bar into a root resource straight away which is not what I want at all. The bottom line is that the root resources can do certain optimizations around using @Path by hoisting the shared path segment on top of the class while subresources can't unless they're prepeared to be root resources too.
This seems a bit inconsistent. IMHO it would be nice for this requirement be relaxed. But this will in turn present an issue for JAX-RS implementations which scan the classpath and make all @Path-annotated classes as root resources. The question is, is it really an issue ?
Thanks, Sergey
>
> Marc.
>
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland