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