Interceptors with InjectionTarget of Dependent scoped beans

[swiegersf.francois.swiegers.gmail.com]

Good day

I'm trying to use an interceptor on a dependent scoped bean that gets its dependencies injected via an InjectionTarget as per the Weld user guide section 16.4.

The injection works fine, but I am not able to get an interceptor to work that I defined on my bean. The reason for this seems to be that the

injectionTarget.produce(ctx)

method does not return a proxied instance, but a direct reference to my bean. My understanding is that interceptors and decorators won't work unless Weld gives me back a proxy.

If I inject the above mentioned bean directly using @Inject, then Weld does create a proxied instance and the interceptor works fine.     

Is this a bug in Weld, or do I need to something special using the InjectionTarget to tell it to return a proxy instead of the concrete instance?

A related question: is it possible to get CDI to wrap an existing instance into a proxy to enable interceptors and decorators to work? My problem is that I don't control the creation of my objects, but I want them to take advantage of CDI's interceptors and dependency injection capabilities. However, looking at InjectionTarget, it does not provide an inject method that returns a proxy.

[asiandub]

hi francois,

first of all: neither did i digg into any framework code, not am i using weld for more than the last weeks - so consider this post as my two cents...

as far as i understand, a dependend scoped bean cannot get proxied at all (http://www.seamframework.org/Community/WeldSpecAManagedBeanWithAPublicFieldHasToBeDependent)

so i would not consider this a bug in Weld.

which leaves the question open how dependent beans do get intercepted...

cheers,

jan

[swiegersf.francois.swiegers.gmail.com]

Hi Jan,

I don't think the spec precludes a dependent bean from being proxied - it simply states that it is not required to be proxied. In the case of a dependent scoped bean using an interceptor or decorator, the CDI implementation can (and without using something magical like AspectJ must) wrap the dependent bean in a proxy to enable the correct behaviour. That is in fact what happens correctly when you inject the dependent bean using the conventional @Inject mechanism.

Barring some fine print in the spec that I missed, I still think the above is a bug in Weld, as the spec clearly indicates that interceptors and decorators are supported for dependent beans, and there is no way that this can be done in Weld without using a proxy.

Regards,
Francois

[swd847]

Barring some fine print in the spec that I missed, I still think the above is a bug in Weld, as the spec clearly indicates that interceptors and decorators are supported for dependent beans, and there is no way that this can be done in Weld without using a proxy.

Currently interceptors are implemented via a proxy, however in the next release of weld they will be implemented via subclassing. You may want to try the latest snapshot and see if you still have the problem.

[swiegersf.francois.swiegers.gmail.com]

Thanks for the response, Stuart. In the above I used the term proxy somewhat loosely, but it is better to be specific to avoid confusion.

This behaviour manifests in the 1.0.2-SNAPSHOT version, not the absolute latest but one that was built sometime last week. When I use @Inject, then I correctly get a javassist subclass of my original bean, but when I use InjectionTarget to create the bean, then I get the raw, unmodified bean.

[pmuir]

Francois, interceptors and decorators should be applied when you call it.produce() - please file an issue in JIRA along with the code you are using to test this, so we can reproduce. Thanks!

[swiegersf.francois.swiegers.gmail.com]

Thanks Pete, I have created WELD-571 with a basic test case.