当具有拦截器或装饰器的bean在CDI中有什么处理规则？

Question

I ran 2 examples in weblogic ( I used a bean with dependent scope):

1)the bean has not any interceptors or decorators: the bean was not proxied

2)the bean has a interceptors : the bean was proxied

I think that there are two types of proxies in CDI:

1)client proxy: This proxy overrides all the non-private methods of the bean class, when these overridden methods are invoked the proxy looks up the correct instance( or proxy of second type) of the bean and then forwards the invocation onto the actual bean instance (based on this link). for dependent scope this proxy is not created

2)there is another proxy for applying interceptors and decorators and it is created when the bean has decorator or interceptors

Is my assumption about second type of proxy correct? Does the specification say anything about it?

Answer 1

You made a nice investigation indeed and you are right for the most part. Here are the details.

Proxy

Normal scoped beans ( @ApplicationScoped , RequestScoped ,...) are indeed proxied, you don't get hold of the actual instance and what you are getting is a client proxy . With @Dependent which is not normal scoped, you basically want to inject new instance every time so there is no need to have it proxied.

The above has some mentions in CDI spec, albeit not precise to give implementation space in which they can manipulate - users should't really care if they have a proxy or not for calling their methods works just fine.

Interceptors and Decorators

Moving on to interceptors - spec says nothing about this from what I know and leaves implementations to choose freely what to do with it. Following details are Weld-specific although from what I recall, OWB has it similar. There aren't really many option how to achieve it anyway.

For every interceptor/decorator, there is a "proxy" created, in fact a subclass, which allows to make interception/decoration happen. This subclass replaces the original bean and all calls go through it (eg it is in the underlying bean store instead of the original instance).

Again, from user perspective, this makes no difference and you shouldn't be worried about it.

Extra tooling for proxies/sublasses

Sometimes, very rarely, and most likely only when you are developing a CDI library , you may truly need to see if the injected bean is a client proxy or a subclass. Weld offers tools for that, every bean which has a client proxy is implementing WeldClientProxy interface from Weld API. This interface allows you to grab the actual instance and some metadata. Likewise, every intercepted and decorated bean is implementing WeldContruct as a marker interface.