<div dir="ltr">Hi Martin,<div><br></div><div>Thanks for the swift action and the reference. I do have one more question looking at the test that was added. It now uses this SLSB:</div><div><br></div><div><div>@Stateless</div><div>public class SLSessionBean {</div><div><br></div><div>    public void ping(){</div><div>    }</div><div><br></div><div>    static final AtomicBoolean DESTROYED = new AtomicBoolean();</div><div><br></div><div>    @PreDestroy</div><div>    public void destroy() {</div><div>        DESTROYED.set(true);</div><div>    }</div><div>}</div></div><div><br></div><div>The assertion in the test is that the (a?) SLSB is actually destroyed, but wasn&#39;t the idea that only the internal reference is destroyed, and the bean just stays in the pool? </div><div><br></div><div>Here it looks like the code intends to destroy a random SLSB instance from the pool. (random, since I guess an internal reference doesn&#39;t stick to the same actual instance of a SLSB, otherwise you would get stateful like semantics).</div><div><br></div><div>Or did I miss something?</div><div><br></div><div>Kind regards,</div><div>Arjan Tijms</div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 11, 2016 at 9:11 AM, Martin Kouba <span dir="ltr">&lt;<a href="mailto:mkouba@redhat.com" target="_blank">mkouba@redhat.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Arjan,<br>
<br>
I believe it&#39;s a Weld bug - you should be able to use Instance.destroy() to discard an internal SLSB proxy. See also &quot;Lifecycle of stateless and singleton session beans&quot; [1]. Tomas Remes created WELD-2148 to track this issue [2].<br>
<br>
Also the &quot;leak&quot; is an expected behaviour. See for example WELD-920 [3] discussion.<br>
<br>
Martin<br>
<br>
[1]<br>
<a href="http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#stateless_lifecycle" rel="noreferrer" target="_blank">http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#stateless_lifecycle</a><br>
<br>
[2]<br>
<a href="https://issues.jboss.org/browse/WELD-2148" rel="noreferrer" target="_blank">https://issues.jboss.org/browse/WELD-2148</a><br>
<br>
[3]<br>
<a href="https://issues.jboss.org/browse/WELD-920" rel="noreferrer" target="_blank">https://issues.jboss.org/browse/WELD-920</a><br>
<br>
Dne 10.5.2016 v 17:11 arjan tijms napsal(a):<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
Hi,<br>
<br>
Given a simple @Stateless bean:<br>
<br>
@Stateless<br>
public class Foo {<br>
     public void bar() {}<br>
}<br>
<br>
Then requesting an instance of this via CDI as follows:<br>
<br>
Foo foo = CDI.current().select(Foo.class).get();<br>
<br>
Causes a lot of leaked proxy instances (at least on Weld). Now what I<br>
guess needs to be done is destroying the proxy, taking Antoine&#39;s answer<br>
here as a lead:<br>
<a href="http://stackoverflow.com/questions/28767536/scope-of-stateless-bean" rel="noreferrer" target="_blank">http://stackoverflow.com/questions/28767536/scope-of-stateless-bean</a><br>
<br>
Only the following throws an UnsupportedOperationException (on Weld<br>
2.3.2, haven&#39;t tested OWB yet)<br>
<br>
Instance&lt;Foo&gt; fooInstance =CDI.current().select(Foo.class);<br>
Foo foo = fooInstance.get();<br>
foo.bar();<br>
fooInstance.destroy(foo);<br>
<br>
The question is, is this how it&#39;s supposed to be done via the spec?<br>
<br>
Implementation wise, what happens in Weld is that the CDI/EJB proxy<br>
(com.test.Foo$Proxy$_$$_Weld$EnterpriseProxy$) in the following code<br>
doesn&#39;t hit the check for a dependent instance (comments in capitals<br>
added by me):<br>
<br>
<br>
     public void destroy(T instance) {<br>
         Preconditions.checkNotNull(instance);<br>
<br>
         // check if this is a proxy of a normal-scoped bean<br>
         if (instance instanceof ProxyObject) {<br>
<br>
             // THIS BRANCH IS TAKEN FOR CDI/EJB PROXY<br>
<br>
             ProxyObject proxy = (ProxyObject) instance;<br>
             if (proxy.getHandler() instanceof ProxyMethodHandler) {<br>
                 ProxyMethodHandler handler = (ProxyMethodHandler)<br>
proxy.getHandler();<br>
                 Bean&lt;?&gt; bean = handler.getBean();<br>
                 Context context =<br>
getBeanManager().getContext(bean.getScope());<br>
                 if (context instanceof AlterableContext) {<br>
                     AlterableContext alterableContext =<br>
(AlterableContext) context;<br>
<br>
                     // CONTEXT IS A DEPENDENTCONTEXTIMPL THAT THROWS<br>
                     // UnsupportedOperationException FROM ITS DESTROY()<br>
METHOD<br>
                     alterableContext.destroy(bean);<br>
                     return;<br>
                 } else {<br>
                     throw BeanLogger.LOG.destroyUnsupported(context);<br>
                 }<br>
             }<br>
         }<br>
<br>
         // check if this is a dependent instance<br>
         CreationalContext&lt;? super T&gt; ctx = getCreationalContext();<br>
         if (ctx instanceof WeldCreationalContext&lt;?&gt;) {<br>
             WeldCreationalContext&lt;? super T&gt; weldCtx = cast(ctx);<br>
<br>
             // PROXY REFERENCES ARE KEPT HERE IN A<br>
             // &quot;dependentInstances&quot; LIST, AND WOULD BE CLEARED HERE<br>
             // BUT THIS CODE IS NEVER REACHED<br>
             weldCtx.destroyDependentInstance(instance);<br>
         }<br>
     }<br>
<br>
Now I wonder, am I doing something wrong (according to the CDI spec), or<br>
could this be a bug in the Weld code?<br>
<br>
Kind regards,<br>
Arjan Tijms<br>
<br>
<br></div></div><span class="">
_______________________________________________<br>
cdi-dev mailing list<br>
<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
<br>
Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.<br>
<br>
</span></blockquote><span class="HOEnZb"><font color="#888888">
<br>
-- <br>
Martin Kouba<br>
Software Engineer<br>
Red Hat, Czech Republic<br>
</font></span></blockquote></div><br></div>