On Jul 8, 2008, at 1:46 PM, Jo Størset wrote:
>
>>> 1) If I wanted to have a Keywords and a Keyword class I can
>>> - use a sub resource locator, but then I have to give up all
>>> support for DI or 'pollute' the parent with the child's
>>> dependencies?
>>> - duplicate the path in the two classes?
>>>
>>> How should I model this effectively?
>> Yes, that is right. Dependencies are only injeced in classes
>> instantieated by the runtime. Marc answered a reason I think, but I
>> didn't know the reason yet. I also think it is useful to allow this
>> injection.
>
> I guess it simply is a necessary trade off that had to be made?
>
The main issue is that the application is in charge of the returned
object's lifecycle so its hard to know when its desirable to inject
and when not.
>>> 2) When I want to supply a representation of a researcher's
>>> keywords, I want to give out url's to them (after all, it's the
>>> web :)
>>>
>>> If I use sub resource locators, there is no way of doing this
>>> except hard coding the concatenated path elements (or something
>>> equivalent) in the representation rendering logic? Does this mean
>>> i'm stuck with not using sub resource locators?
>>>
>>> I am thinking that effective means of using the same mechanism for
>>> request mapping and url generation must be important for a rest
>>> api? But maybe it's to difficult or to early days?
>> You could get a UriInfo from the runtime in a resource method, if
>> you annotate it with @Context. Does this solve your issue?
>
> I do use the UriInfo/UriBuilder, and it is useful.
>
> What I am trying to do is make a framework for the app developers,
> so they don't have to manually create the representations (and put
> together each url manually), mixed into and partially duplicating
> the "controller logic" the resource (with annotations) represents.
>
> I get a root resource url by something like uriBuilder.path(clazz).
> But if a resource is a sub resource, there's no way to ask what urls
> (since it might be multiple) it is available on.
>
One thing you might be able to do is to use UriInfo in your message
body writer and use the two ancestor methods to obtain URIs for the
instances of the objects the framework traversed while dispatching the
request.
> This information is available to the container through the jax-rs
> annotations, so it would be nice to be able to get them, or maybe to
> annotate one of them as primary or something.
>
The runtime can take a URI and find the right object to dispatch the
request to but it can't figure out the set of URIs that will be
dispatched to a particular class. The reason is that the return type
from a sub-resource locator isn't known until runtime - a subresource
locator can, e.g. return Object provided the actual instance returned
is an instance of a JAX-RS resource class.
We hit the same issue in Jersey when we generate WADL, once you hit a
subresource locator it gets difficult to traverse the tree further in
a reliable way.
Marc.
---
Marc Hadley <marc.hadley at sun.com>
CTO Office, Sun Microsystems.