<div dir="ltr">Martin,<br><br><div class="gmail_quote"><div dir="ltr">On Mon, May 16, 2016 at 8:06 AM Martin Kouba &lt;<a href="mailto:mkouba@redhat.com">mkouba@redhat.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Dne 16.5.2016 v 13:34 John D. Ament napsal(a):<br>
&gt;<br>
&gt; Martin,<br>
&gt;<br>
&gt;<br>
&gt; On Mon, May 16, 2016 at 3:54 AM Martin Kouba &lt;<a href="mailto:mkouba@redhat.com" target="_blank">mkouba@redhat.com</a><br>
&gt; &lt;mailto:<a href="mailto:mkouba@redhat.com" target="_blank">mkouba@redhat.com</a>&gt;&gt; wrote:<br>
&gt;<br>
&gt;     Dne 15.5.2016 v 17:14 John D. Ament napsal(a):<br>
&gt;      &gt; Romain,<br>
&gt;      &gt;<br>
&gt;      &gt; On Sun, May 15, 2016 at 11:05 AM Romain Manni-Bucau<br>
&gt;      &gt; &lt;<a href="mailto:rmannibucau@gmail.com" target="_blank">rmannibucau@gmail.com</a> &lt;mailto:<a href="mailto:rmannibucau@gmail.com" target="_blank">rmannibucau@gmail.com</a>&gt;<br>
&gt;     &lt;mailto:<a href="mailto:rmannibucau@gmail.com" target="_blank">rmannibucau@gmail.com</a> &lt;mailto:<a href="mailto:rmannibucau@gmail.com" target="_blank">rmannibucau@gmail.com</a>&gt;&gt;&gt; wrote:<br>
&gt;      &gt;<br>
&gt;      &gt;     Hi Jon<br>
&gt;      &gt;<br>
&gt;      &gt;     Le 15 mai 2016 16:15, &quot;John D. Ament&quot; &lt;<a href="mailto:john.d.ament@gmail.com" target="_blank">john.d.ament@gmail.com</a><br>
&gt;     &lt;mailto:<a href="mailto:john.d.ament@gmail.com" target="_blank">john.d.ament@gmail.com</a>&gt;<br>
&gt;      &gt;     &lt;mailto:<a href="mailto:john.d.ament@gmail.com" target="_blank">john.d.ament@gmail.com</a><br>
&gt;     &lt;mailto:<a href="mailto:john.d.ament@gmail.com" target="_blank">john.d.ament@gmail.com</a>&gt;&gt;&gt; a écrit :<br>
&gt;      &gt;      &gt;<br>
&gt;      &gt;      &gt; Hey guys<br>
&gt;      &gt;      &gt;<br>
&gt;      &gt;      &gt; Seems like we have some issues in JIRA all focused on managing<br>
&gt;      &gt;     the lifecycle of Dependent scoped beans.  It also seems like<br>
&gt;     we have<br>
&gt;      &gt;     many differing opinions about how to manage them.<br>
&gt;      &gt;      &gt;<br>
&gt;      &gt;      &gt; - Martin raised a PR to add a release() method to Instance to<br>
&gt;      &gt;     help destroy a dependent bean<br>
&gt;     <a href="https://github.com/cdi-spec/cdi/pull/286" rel="noreferrer" target="_blank">https://github.com/cdi-spec/cdi/pull/286</a><br>
&gt;      &gt;      &gt; - I raised a PR <a href="https://github.com/cdi-spec/cdi/pull/289" rel="noreferrer" target="_blank">https://github.com/cdi-spec/cdi/pull/289</a> to<br>
&gt;      &gt;     update the spec to clarify how to manage a dependent scoped bean.<br>
&gt;      &gt;      &gt;<br>
&gt;      &gt;      &gt; Right now, it seems that the big disagreement is whether<br>
&gt;      &gt;     Instance.destroy() can destroy objects not created by it (the<br>
&gt;     case<br>
&gt;      &gt;     being around the CDI utility class, being an impl of<br>
&gt;     Instance).  I&#39;m<br>
&gt;      &gt;     currently heavily against Martin&#39;s proposed changes, but want<br>
&gt;     to get<br>
&gt;      &gt;     input from others on the group to understand their perspective.<br>
&gt;      &gt;      &gt;<br>
&gt;      &gt;      &gt; - Does the spec require destroy() to be called only on<br>
&gt;     instances<br>
&gt;      &gt;     that it created?  When I read 5.6.1 the only requirement I see is<br>
&gt;      &gt;     that it has to be a dependent scoped bean.  Note when I ask<br>
&gt;     this I&#39;m<br>
&gt;      &gt;     asking from the spec perspective, its a different problem if<br>
&gt;     there&#39;s<br>
&gt;      &gt;     some issues with implementations following suite (I would imagine<br>
&gt;      &gt;     there needs to be some shared global registry of dependent scoped<br>
&gt;      &gt;     beans for this to work).<br>
&gt;      &gt;      &gt;<br>
&gt;      &gt;<br>
&gt;      &gt;     Sound the only clean impl. Any other is not symmetric and<br>
&gt;      &gt;     potentially lead to &quot;oops this time it didnt work&quot;. I also not<br>
&gt;      &gt;     seeing any use case limitation with that so think it is the same<br>
&gt;      &gt;     solution<br>
&gt;      &gt;<br>
&gt;      &gt;<br>
&gt;      &gt; I&#39;m not sure I follow or if this isn&#39;t an answer to &quot;Does the spec<br>
&gt;      &gt; require destroy() to be called only on instances that it created?&quot; ?<br>
&gt;      &gt;<br>
&gt;      &gt; Anyways I did look a bit closer and it seems that Martin&#39;s<br>
&gt;     statement is<br>
&gt;      &gt; consistent with how OWB works,<br>
&gt;      &gt;<br>
&gt;     <a href="https://github.com/apache/openwebbeans/blob/trunk/webbeans-impl/src/main/java/org/apache/webbeans/inject/instance/InstanceImpl.java#L293" rel="noreferrer" target="_blank">https://github.com/apache/openwebbeans/blob/trunk/webbeans-impl/src/main/java/org/apache/webbeans/inject/instance/InstanceImpl.java#L293</a><br>
&gt;     so<br>
&gt;      &gt; I wonder if there&#39;s a part of the spec I&#39;m missing, or if there<br>
&gt;     was some<br>
&gt;      &gt; offline agreement on how to understand it.<br>
&gt;<br>
&gt;     John, I believe Instance CANNOT be used to destroy a dependent bean<br>
&gt;     instance it didn&#39;t created, because a dependent bean instance doesn&#39;t<br>
&gt;     know the dependent objects it depends on - that&#39;s what CreationalContext<br>
&gt;     is for.<br>
&gt;<br>
&gt;<br>
&gt; This is the area I&#39;m looking for clarification around.  Where in the<br>
&gt; spec is this mandated?<br>
<br>
I think it&#39;s implied. When you look at &quot;6.1.1. The CreationalContext<br>
interface&quot;, there is:<br>
<br>
&quot;Contextual.create() should use the given CreationalContext when<br>
obtaining contextual references to inject, as defined in Contextual<br>
reference for a bean, in order to ensure that any dependent objects are<br>
associated with the contextual instance that is being created.&quot;<br>
<br>
and also:<br>
<br>
&quot;Contextual.destroy() should call release() to allow the container to<br>
destroy dependent objects of the contextual instance.&quot;<br>
<br>
and &quot;6.2. The Context interface&quot;:<br>
<br>
&quot;The context object must pass the same instance of CreationalContext to<br>
Contextual.destroy() that it passed to Contextual.create() when it<br>
created the instance.&quot;<br>
<br>
And for dependent beans there is no real context which could hold a<br>
reference to a CreationalContext. Each Instance&lt;T&gt; has its own<br>
CreationalContext which only tracks the dependent instances produced by<br>
a given Instance. Instance&lt;T&gt; does not know anything about<br>
CreationalContexts of other dependent instances...<br></blockquote><div><br></div><div><br></div><div>I think I&#39;m starting to see your point.  However, if its mandated that Instance uses a creational context to create a bean, we should call that out.  Right now the text says that it will retrieve a bean, but realistically for dependent it&#39;s creating a bean.</div><div><br></div><div>Maybe something along the lines of </div><div><br></div><div>&quot;In the case of the target bean being a dependent scoped bean, the instance object used to retrieve that bean will retain a reference to the creational context used to create that bean.  That creational context will be used to destroy the bean when calling destroy()&quot;</div><div><br></div><div>I would still like us to explore ways to do this without requiring the original instance, for the case of CDI.current() usage.</div><div><br></div><div>John</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
&gt;<br>
&gt;     So if you pass any dependent instance to Instance.destroy() there is no<br>
&gt;     CreationalContext apart from the one Instance&lt;&gt; has. In other words you<br>
&gt;     wouldn&#39;t be able to destroy the @Dependent dependencies of a @Dependent<br>
&gt;     bean instane. Does it make sense?<br>
&gt;<br>
&gt;     See also <a href="https://issues.jboss.org/browse/CDI-519" rel="noreferrer" target="_blank">https://issues.jboss.org/browse/CDI-519</a> (cdi-spec/cdi/pull/278<br>
&gt;     is already merged).<br>
&gt;<br>
&gt;<br>
&gt;      &gt;<br>
&gt;      &gt; John<br>
&gt;      &gt;<br>
&gt;      &gt;      &gt; - Do we want two methods that effectively do the same<br>
&gt;     thing?  I<br>
&gt;      &gt;     don&#39;t see a strong difference between the two.<br>
&gt;      &gt;      &gt;<br>
&gt;      &gt;      &gt; On the flipside, my change is more a spec clarification.  I&#39;m<br>
&gt;      &gt;     thinking more now that it belongs as a reword of 5.6.1 to clarify<br>
&gt;      &gt;     how to use destroy() on dependent beans, rather than where I put<br>
&gt;      &gt;     it.  I think realistically we have all of the tools needed to<br>
&gt;     manage<br>
&gt;      &gt;     the lifecycle of these classes, just need to clarify them for<br>
&gt;     people<br>
&gt;      &gt;     to use.<br>
&gt;      &gt;      &gt;<br>
&gt;      &gt;      &gt; John<br>
&gt;      &gt;      &gt;<br>
&gt;      &gt;<br>
&gt;      &gt;      &gt; _______________________________________________<br>
&gt;      &gt;      &gt; cdi-dev mailing list<br>
&gt;      &gt;      &gt; <a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a> &lt;mailto:<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a>&gt;<br>
&gt;     &lt;mailto:<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a> &lt;mailto:<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a>&gt;&gt;<br>
&gt;      &gt;      &gt; <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
&gt;      &gt;      &gt;<br>
&gt;      &gt;      &gt; Note that for all code provided on this list, the provider<br>
&gt;      &gt;     licenses the code under the Apache License, Version 2<br>
&gt;      &gt;     (<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<br>
&gt;      &gt;     ideas provided on this list, the provider waives all patent and<br>
&gt;      &gt;     other intellectual property rights inherent in such information.<br>
&gt;      &gt;<br>
&gt;      &gt;<br>
&gt;      &gt;<br>
&gt;      &gt; _______________________________________________<br>
&gt;      &gt; cdi-dev mailing list<br>
&gt;      &gt; <a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a> &lt;mailto:<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a>&gt;<br>
&gt;      &gt; <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
&gt;      &gt;<br>
&gt;      &gt; Note that for all code provided on this list, the provider<br>
&gt;     licenses the code under the Apache License, Version 2<br>
&gt;     (<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<br>
&gt;     ideas provided on this list, the provider waives all patent and<br>
&gt;     other intellectual property rights inherent in such information.<br>
&gt;      &gt;<br>
&gt;<br>
&gt;     --<br>
&gt;     Martin Kouba<br>
&gt;     Software Engineer<br>
&gt;     Red Hat, Czech Republic<br>
&gt;<br>
<br>
--<br>
Martin Kouba<br>
Software Engineer<br>
Red Hat, Czech Republic<br>
</blockquote></div></div>