[seam-dev] Retrieving the Bean object for an interceptor

[Stuart Douglas]

________________________________________
From: Marius Bogoevici [marius.bogoevici at gmail.com]
Sent: Thursday, 22 April 2010 4:24 PM
To: Gavin King
Cc: Stuart Douglas; seam-dev at lists.jboss.org
Subject: Re: [seam-dev] Retrieving the Bean object for an interceptor

On 10-04-22 1:44 AM, Gavin King wrote:
> On Thu, Apr 22, 2010 at 12:38 AM, Marius Bogoevici
> <marius.bogoevici at gmail.com>  wrote:
>
>> On 10-04-21 10:36 PM, Stuart Douglas wrote:
>>
>>> I have attempted to add a temporary fix for this issue to weld-extensions to allow interceptors to get at the AnnotatedType of the object being intercepted.
>>>
>>> The extension wraps the InjectionTarget of Beans that need this functionality, and the inject method of the InjectionTarget stores a mapping from the instance to the AnnotatedType in a WeakHashMap.
>>>
>>> I have a few questions:
>>>
>>> - Is InvocationContext.getTarget() guaranteed to return the instance of the bean or can it return a proxy? If it can return a proxy this technique is not going to work.
>>>
>>>
>> The Interceptor specification says just that "getTarget() returns the
>> associated target instance", so that would normally mean  "the original
>> intercepted instance". The introduction of decorators made things more
>> complicated, and in the current implementation (1.0.1), getTarget() will
>> return the decorator proxy if the bean has both interceptors and
>> decorators.
>>
> Then that is a bug, since it is contrary to the specified behavior of
> getTarget().
>
>Right - as I said, this needs to/will change in 1.0.2. In the comment
>that follows I linked it to the subclassing change, but, quite frankly,
>I think that it can be fixed even in the absence of that.
>> However, once we move to subclassing (1.0.2), the call will
>> return the single instrumented instance, which is essentially a subclass
>> of the bean class. It would be necessary to retrieve the original bean
>> class from that. But I can see a few options for doing that, one being a
>> mixin interface with methods that can retrieve information about the
>> original type of the target object.
>>
> Hrm. That's a problem I had not thought of with the subclassing
> approach. The assumption in EJB is that getTarget() returns an
> unintercepted/undecorated reference. Urm.
>
>I suppose that as long as the invocations on getTarget() will not be
>intercepted/decorated, it should be alright. The fact that the instance
>is not a bean class instance [but a subclass of it] remains a problem,
>but I don't think that it is a direct violation of the specification, is it?

If we end up being able to inject the AnnotatedType then I don't see it being that much of a problem, as we should be able to do AnnotatedType.getJavaClass() to get the 'real' type.

Stuart