<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, May 11, 2016 at 7:05 AM Martin Kouba <<a href="mailto:mkouba@redhat.com">mkouba@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dne 11.5.2016 v 11:56 arjan tijms napsal(a):<br>
> Hi,<br>
><br>
> On Wed, May 11, 2016 at 11:43 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>>> wrote:<br>
><br>
> I don't think so. Remember that Instace is more like a "factory" and<br>
> not only for @Dependent objects. What would actually close() do?<br>
><br>
><br>
> I'd intuitively say release and where appropriate destroy all beans that<br>
> were created from that particular instance of uhm Instance. But maybe<br>
> the existing semantics of Instance aren't a good fit for that.<br>
><br>
> Thinking out loud, maybe an AutoInstance variant?<br>
><br>
> try (AutoInstance<Foo> fooInstance = CDI.current().autoSelect(Foo.class)) {<br>
><br>
> Foo foo = fooInstance.get();<br>
> foo.bar();<br>
> }<br>
<br>
Well, I'm not sure it's worth adding a new interface + method in CDI API<br>
if the only purpose is to call Instance.destroy() (or possibly release()<br>
- see cdi/pull/286) automatically.<br>
<br>
Even now it's possible to have a wrapper/helper class for this, e.g.<br>
something like:<br>
<br>
class AutoDestroyable<T> implements AutoCloseable {<br>
<br>
static AutoDestroyable<T> from(Instance<T> instance) {<br>
return new AutoDestroyable(instance);<br>
}<br>
<br>
private final Instance<T> instance;<br>
<br>
private final T value;<br>
<br>
private AutoDestroyable(Instance<T> instance) {<br>
this.instance = instance;<br>
this.value = instance.get();<br>
}<br>
<br>
T get() {<br>
return value;<br>
}<br>
<br>
void close() {<br>
instance.destroy(value);<br>
}<br>
<br>
}<br>
<br>
try (AutoDestroyable<Foo> destroyableFoo =<br>
AutoDestroyable.from(CDI.current().select(Foo.class))) {<br>
Foo foo = destroyableFoo.get();<br>
foo.bar();<br>
}<br>
<br></blockquote><div><br></div><div>To accomplish this without a spec change, means that essentially every app in the world needs this utility. Its more scalable to write the fix once and get it in the spec.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
><br>
> autoSelect could even throw early if the selected bean is not dependent<br>
> scoped. But as mentioned, just thinking out loud here.<br>
><br>
> Kind regards,<br>
> Arjan Tijms<br>
><br>
><br>
><br>
> Also the users would be tempted to use this for injected Instance<br>
> which does not make sense.<br>
><br>
><br>
> try (Instance<Foo> fooInstance =CDI.current().select(Foo.class)) {<br>
><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<br>
> have one more<br>
> question looking at the test that was added. It now<br>
> uses this SLSB:<br>
><br>
> @Stateless<br>
> public class SLSessionBean {<br>
><br>
> public void ping(){<br>
> }<br>
><br>
> static final AtomicBoolean DESTROYED = new<br>
> 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<br>
> SLSB<br>
> instance<br>
> from the pool. (random, since I guess an internal<br>
> reference doesn't<br>
> stick to the same actual instance of a SLSB, otherwise<br>
> 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<br>
> <<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>><br>
> <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>>><br>
> <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>><br>
> <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<br>
> proxy. See also<br>
> "Lifecycle of stateless and singleton session<br>
> beans" [1]. Tomas<br>
> Remes created WELD-2148 to track this issue [2].<br>
><br>
> Also the "leak" is an expected behaviour. See for<br>
> 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<br>
> follows:<br>
><br>
> Foo foo = CDI.current().select(Foo.class).get();<br>
><br>
> Causes a lot of leaked proxy instances (at<br>
> least on<br>
> Weld). Now<br>
> what I<br>
> guess needs to be done is destroying the<br>
> 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<br>
> =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<br>
> be done<br>
> via the spec?<br>
><br>
> Implementation wise, what happens in Weld is<br>
> that the<br>
> CDI/EJB proxy<br>
> (com.test.Foo$Proxy$_$$_Weld$EnterpriseProxy$)<br>
> 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<br>
> CDI/EJB PROXY<br>
><br>
> ProxyObject proxy =<br>
> (ProxyObject) instance;<br>
> if (proxy.getHandler() instanceof<br>
> ProxyMethodHandler) {<br>
> ProxyMethodHandler handler =<br>
> (ProxyMethodHandler)<br>
> proxy.getHandler();<br>
> Bean<?> bean =<br>
> handler.getBean();<br>
> Context context =<br>
> getBeanManager().getContext(bean.getScope());<br>
> if (context instanceof<br>
> AlterableContext) {<br>
> AlterableContext<br>
> alterableContext =<br>
> (AlterableContext) context;<br>
><br>
> // CONTEXT IS A<br>
> DEPENDENTCONTEXTIMPL THAT<br>
> THROWS<br>
> //<br>
> UnsupportedOperationException<br>
> FROM ITS<br>
> DESTROY()<br>
> METHOD<br>
><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<br>
> WeldCreationalContext<?>) {<br>
> WeldCreationalContext<? super T><br>
> weldCtx<br>
> = cast(ctx);<br>
><br>
> // PROXY REFERENCES ARE KEPT<br>
> HERE IN A<br>
> // "dependentInstances" LIST,<br>
> AND WOULD<br>
> BE CLEARED<br>
> HERE<br>
> // BUT THIS CODE IS NEVER REACHED<br>
><br>
> weldCtx.destroyDependentInstance(instance);<br>
> }<br>
> }<br>
><br>
> Now I wonder, am I doing something wrong<br>
> (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>
> <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>>><br>
> <mailto:<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a><br>
> <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><br>
> <mailto:<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,<br>
> the provider<br>
> licenses the code under the Apache License,<br>
> Version 2<br>
><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<br>
> waives all<br>
> patent and<br>
> other intellectual property rights inherent in<br>
> 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>
><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>
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>
</blockquote></div></div>