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]
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(a)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(a)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(a)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(a)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(a)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.