Hi,
Regarding #1: Sometimes I do have subresources that always come from a
single parent, for the sake of code organization and to avoid huge
resource classes. But in this case, what I'md oing is exactly as you
describe: a subresource that is NOT bound to a specific parent.
What I have made is a generic attachments subresource that allows
"files" to be attached under various resources:
/customers/{customerId}/resourceA/{resourceA_key}/attachments
/customers/{customerId}/resourceB/{resourceB_key}/attachments
/customers/{customerId}/resourceC/{resourceC_key}/attachments
resourceA, resourceB, resourceC all implement an interface (let's call
it AttachableResource) that has a .getSomething() method. My intent
was to try:
@ParentRef AttachableResource parent;
then the subresources could do parent.getSomething().
This really is what you said:
"Because what you really want is not a reference to the parent
resource itself, but some data the parent resource provides access
to."
#3 is what I'm doing now. What I pasted above is simplified; the real
situation has deeper paths, and to get to some of the information I
need from various parent resources I end up passing information down
and calling .setSomething() after creation. It's "okay" but not
great. I was looking for a more IOC approach.
What has me thinking here is your #2. The information I need (at
least for now) is actually in the request path. I could have my
attachments subresource parse it out of there. I was just trying to
avoid having my subresource have to understand things about paths
above it - that seemed bad to me.
Tell me what you think of this idea. Maybe I should create my own
context container, let's call it an AttachmentInfo object, and make a
provider that generates one that is @RequestScoped ... then have the
paths along the way (as they delegate) add information to it. My
CustomerResource could add the customerId to this object, any other
subresource along the way could add what it needed, and the
attachments resource could inject this request scoped item and pull
out information it thinks it needs.
Does this seem hackish?
--Chris
On Mon, Aug 27, 2012 at 6:04 AM, Marek Potociar
<marek.potociar_at_oracle.com> wrote:
> In general I find @ParentRef more harmful than useful. So it will most
> likely be ditched in Jersey 2.0 (while the ResourceContext will be promoted
> directly to the JAX-RS API).
>
> A few reasons why I find @ParentRef harmful:
>
> sub-resources are in general not bound to a single parent resource (and
> should not be...)
> all resources should be mostly focused on values contained in the request
> itself (IOW should not need any special parent-resource information)
> if #2 does not apply for your special case, you can still use a setter on
> the sub-resource instance to provide the additional post-creation
> initialization data. Because what you really want is not a reference to the
> parent resource itself, but some data the parent resource provides access
> to.
>
>
> Anyway, I'd be interested to hear about any use-case where the above does
> not apply or is not practical. So please, in case you have such use case,
> I'd be interested to hear more details about it.
>
> Marek
>
> On Aug 26, 2012, at 11:12 PM, Christopher Piggott <cpiggott_at_gmail.com>
> wrote:
>
> @ParentRef in a CDI/glassfish/weld environment doesn't seem to return
> anything useful. The real object I want to get to is an
> AttachmentsSubResource, but what my subresource thinks @ParentRef
> really points to is an object of type:
>
> AttachmentsSubResource$Proxy$_$$_WeldClientProxy
>
> and I'm not sure what I can do with that ...
>
> Has anybody else worked with this?
>
> --Chris
>
>