<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, May 11, 2016 at 5:58 AM arjan tijms <<a href="mailto:arjan.tijms@gmail.com">arjan.tijms@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<br><div class="gmail_extra"><br><div class="gmail_quote"></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, May 11, 2016 at 11:43 AM, Martin Kouba <span dir="ltr"><<a href="mailto:mkouba@redhat.com" target="_blank">mkouba@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I don't think so. Remember that Instace is more like a "factory" and not only for @Dependent objects. What would actually close() do? </blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>I'd intuitively say release and where appropriate destroy all beans that were created from that particular instance of uhm Instance. But maybe the existing semantics of Instance aren't a good fit for that.</div><div><br></div><div>Thinking out loud, maybe an AutoInstance variant?</div><div><br></div><div><div>try (AutoInstance<Foo> fooInstance = CDI.current().autoSelect(Foo.class)) {</div></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div><br></div><div> Foo foo = fooInstance.get();</div><div> foo.bar();</div><div>}</div></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div><br></div></div></div></div></blockquote><div><br></div><div>Sounds very similar to my original proposal, I would just use dependent in this case, unless we want to hide that from the developer.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>autoSelect could even throw early if the selected bean is not dependent scoped. But as mentioned, just thinking out loud here.</div><div><br></div><div>Kind regards,</div><div>Arjan Tijms</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Also the users would be tempted to use this for injected Instance which does not make sense.<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
try (Instance<Foo> fooInstance =CDI.current().select(Foo.class)) {<div><div><br>
Foo foo = fooInstance.get();<br>
foo.bar();<br>
}<br>
<br>
Kind regards,<br>
Arjan Tijms<br>
<br>
<br>
<br>
<br>
Martin<br>
<br>
Dne 11.5.2016 v 10:40 arjan tijms napsal(a):<br>
<br>
Hi Martin,<br>
<br>
Thanks for the swift action and the reference. I do have one more<br>
question looking at the test that was added. It now uses this SLSB:<br>
<br>
@Stateless<br>
public class SLSessionBean {<br>
<br>
public void ping(){<br>
}<br>
<br>
static final AtomicBoolean DESTROYED = new AtomicBoolean();<br>
<br>
@PreDestroy<br>
public void destroy() {<br>
DESTROYED.set(true);<br>
}<br>
}<br>
<br>
The assertion in the test is that the (a?) SLSB is actually<br>
destroyed,<br>
but wasn't the idea that only the internal reference is<br>
destroyed, and<br>
the bean just stays in the pool?<br>
<br>
Here it looks like the code intends to destroy a random SLSB<br>
instance<br>
from the pool. (random, since I guess an internal reference doesn't<br>
stick to the same actual instance of a SLSB, otherwise you would get<br>
stateful like semantics).<br>
<br>
Or did I miss something?<br>
<br>
Kind regards,<br>
Arjan Tijms<br>
<br>
<br>
<br>
<br>
On Wed, May 11, 2016 at 9:11 AM, Martin Kouba <<a href="mailto:mkouba@redhat.com" target="_blank">mkouba@redhat.com</a><br>
<mailto:<a href="mailto:mkouba@redhat.com" target="_blank">mkouba@redhat.com</a>><br></div></div><div><div>
<mailto:<a href="mailto:mkouba@redhat.com" target="_blank">mkouba@redhat.com</a> <mailto:<a href="mailto:mkouba@redhat.com" target="_blank">mkouba@redhat.com</a>>>> wrote:<br>
<br>
Hi Arjan,<br>
<br>
I believe it's a Weld bug - you should be able to use<br>
Instance.destroy() to discard an internal SLSB proxy. See also<br>
"Lifecycle of stateless and singleton session beans" [1]. Tomas<br>
Remes created WELD-2148 to track this issue [2].<br>
<br>
Also the "leak" is an expected behaviour. See for example<br>
WELD-920<br>
[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>
<br>
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<br>
Weld). Now<br>
what I<br>
guess needs to be done is destroying the proxy, taking<br>
Antoine's<br>
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<br>
UnsupportedOperationException (on Weld<br>
2.3.2, haven't tested OWB yet)<br>
<br>
Instance<Foo> 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's supposed to be done<br>
via the spec?<br>
<br>
Implementation wise, what happens in Weld is that the<br>
CDI/EJB proxy<br>
(com.test.Foo$Proxy$_$$_Weld$EnterpriseProxy$) in the<br>
following code<br>
doesn't hit the check for a dependent instance<br>
(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<br>
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<br>
ProxyMethodHandler) {<br>
ProxyMethodHandler handler =<br>
(ProxyMethodHandler)<br>
proxy.getHandler();<br>
Bean<?> bean = handler.getBean();<br>
Context context =<br>
getBeanManager().getContext(bean.getScope());<br>
if (context instanceof<br>
AlterableContext) {<br>
AlterableContext alterableContext =<br>
(AlterableContext) context;<br>
<br>
// CONTEXT IS A<br>
DEPENDENTCONTEXTIMPL THAT<br>
THROWS<br>
// UnsupportedOperationException<br>
FROM ITS<br>
DESTROY()<br>
METHOD<br>
alterableContext.destroy(bean);<br>
return;<br>
} else {<br>
throw<br>
BeanLogger.LOG.destroyUnsupported(context);<br>
}<br>
}<br>
}<br>
<br>
// check if this is a dependent instance<br>
CreationalContext<? super T> ctx =<br>
getCreationalContext();<br>
if (ctx instanceof WeldCreationalContext<?>) {<br>
WeldCreationalContext<? super T> weldCtx<br>
= cast(ctx);<br>
<br>
// PROXY REFERENCES ARE KEPT HERE IN A<br>
// "dependentInstances" LIST, AND WOULD<br>
BE CLEARED<br>
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<br>
the CDI<br>
spec), or<br>
could this be a bug in the Weld code?<br>
<br>
Kind regards,<br>
Arjan Tijms<br>
<br>
<br>
_______________________________________________<br>
cdi-dev mailing list<br>
<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a> <mailto:<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a>><br></div></div>
<mailto:<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a> <mailto:<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a>>><span><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<br>
licenses the code under the Apache License, Version 2<br>
(<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<br>
all other<br>
ideas provided on this list, the provider waives all<br>
patent and<br>
other intellectual property rights inherent in such<br>
information.<br>
<br>
<br>
--<br>
Martin Kouba<br>
Software Engineer<br>
Red Hat, Czech Republic<br>
<br>
<br>
<br>
--<br>
Martin Kouba<br>
Software Engineer<br>
Red Hat, Czech Republic<br>
<br>
<br>
</span></blockquote><div><div>
<br>
-- <br>
Martin Kouba<br>
Software Engineer<br>
Red Hat, Czech Republic<br>
</div></div></blockquote></div></div></div>
_______________________________________________<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.</blockquote></div></div>