[cdi-dev] Destroying @Stateless proxies obtained via CDI.current().select()

Martin Kouba mkouba at redhat.com
Wed May 11 04:15:24 EDT 2016


Just to be clear: we're not talking about client proxies (contextual 
references) but contextual instances. For a SLSB when 
Contextual.create() is called the container should create an internal 
reference to the session bean and when the destroy() method is called, 
the container should discard this internal reference.

See also 7.3.3. Lifecycle of stateless and singleton session beans [1].

Martin

[1]
http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#stateless_lifecycle

Dne 11.5.2016 v 09:30 Mark Struberg napsal(a):
> Imo the proxy is under the full control of the user.
>
> Note that it is _not_ necessary to create a new proxy instance for each usage of a bean. All of the usages could really re-use the same proxy instance. Which of course internally points to different Contextual Instances...
>
>
> In OWB we have a single proxy instance which we share across all Contextual Instances of the same Bean<T>.
> You will hit the same issue when serialising the proxy, etc.
> Sounds like an implementation glitch. But it should be easy to fix for Martin and Co.
>
>
> LieGrue,
> strub
>
>
>
> On Wednesday, 11 May 2016, 1:36, John D. Ament <john.d.ament at gmail.com> wrote:
>
>
>>
>>
>> Arjan,
>>
>>
>> So this recently came up as well with a PR raised to clarify how instance is used to destroy references: https://github.com/cdi-spec/cdi/pull/286
>>
>>
>> Take a look at the last paragraph here: http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#dynamic_lookup
>>
>>
>> John
>>
>> On Tue, May 10, 2016 at 11:11 AM arjan tijms <arjan.tijms at gmail.com> wrote:
>>
>> Hi,
>>>
>>>
>>> Given a simple @Stateless bean:
>>>
>>>
>>> @Stateless
>>> public class Foo {
>>>     public void bar() {}
>>> }
>>>
>>>
>>> Then requesting an instance of this via CDI as follows:
>>>
>>>
>>> Foo foo = CDI.current().select(Foo.class).get();
>>>
>>>
>>> Causes a lot of leaked proxy instances (at least on Weld). Now what I guess needs to be done is destroying the proxy, taking Antoine's answer here as a lead: http://stackoverflow.com/questions/28767536/scope-of-stateless-bean
>>>
>>>
>>> Only the following throws an UnsupportedOperationException (on Weld 2.3.2, haven't tested OWB yet)
>>>
>>>
>>> Instance<Foo> fooInstance =CDI.current().select(Foo.class);
>>> Foo foo = fooInstance.get();
>>> foo.bar();
>>> fooInstance.destroy(foo);
>>>
>>>
>>> The question is, is this how it's supposed to be done via the spec?
>>>
>>>
>>> Implementation wise, what happens in Weld is that the CDI/EJB proxy (com.test.Foo$Proxy$_$$_Weld$EnterpriseProxy$) in the following code doesn't hit the check for a dependent instance (comments in capitals added by me):
>>>
>>>
>>>
>>>
>>>     public void destroy(T instance) {
>>>         Preconditions.checkNotNull(instance);
>>>
>>>
>>>         // check if this is a proxy of a normal-scoped bean
>>>         if (instance instanceof ProxyObject) {
>>>
>>>
>>>             // THIS BRANCH IS TAKEN FOR CDI/EJB PROXY
>>>
>>>
>>>             ProxyObject proxy = (ProxyObject) instance;
>>>             if (proxy.getHandler() instanceof ProxyMethodHandler) {
>>>                 ProxyMethodHandler handler = (ProxyMethodHandler) proxy.getHandler();
>>>                 Bean<?> bean = handler.getBean();
>>>                 Context context = getBeanManager().getContext(bean.getScope());
>>>                 if (context instanceof AlterableContext) {
>>>                     AlterableContext alterableContext = (AlterableContext) context;
>>>
>>>                     // CONTEXT IS A DEPENDENTCONTEXTIMPL THAT THROWS
>>>                     // UnsupportedOperationException FROM ITS DESTROY() METHOD
>>>                     alterableContext.destroy(bean);
>>>                     return;
>>>                 } else {
>>>                     throw BeanLogger.LOG.destroyUnsupported(context);
>>>                 }
>>>             }
>>>         }
>>>
>>>
>>>         // check if this is a dependent instance
>>>         CreationalContext<? super T> ctx = getCreationalContext();
>>>         if (ctx instanceof WeldCreationalContext<?>) {
>>>             WeldCreationalContext<? super T> weldCtx = cast(ctx);
>>>
>>>
>>>             // PROXY REFERENCES ARE KEPT HERE IN A
>>>             // "dependentInstances" LIST, AND WOULD BE CLEARED HERE
>>>             // BUT THIS CODE IS NEVER REACHED
>>>             weldCtx.destroyDependentInstance(instance);
>>>         }
>>>     }
>>>
>>>
>>> Now I wonder, am I doing something wrong (according to the CDI spec), or could this be a bug in the Weld code?
>>>
>>>
>>> Kind regards,
>>> Arjan Tijms
> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>
>>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>>
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>>
>>
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
>
> Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.
>

-- 
Martin Kouba
Software Engineer
Red Hat, Czech Republic


More information about the cdi-dev mailing list