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

[Marius Bogoevici]

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?