<div dir="ltr">Romain,<br><br><div class="gmail_quote"><div dir="ltr">On Sun, May 15, 2016 at 11:05 AM Romain Manni-Bucau <<a href="mailto:rmannibucau@gmail.com">rmannibucau@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Hi Jon</p>
<p dir="ltr">Le 15 mai 2016 16:15, "John D. Ament" <<a href="mailto:john.d.ament@gmail.com" target="_blank">john.d.ament@gmail.com</a>> a écrit :<br>
><br>
> Hey guys<br>
><br>
> Seems like we have some issues in JIRA all focused on managing the lifecycle of Dependent scoped beans. It also seems like we have many differing opinions about how to manage them.<br>
><br>
> - Martin raised a PR to add a release() method to Instance to help destroy a dependent bean <a href="https://github.com/cdi-spec/cdi/pull/286" target="_blank">https://github.com/cdi-spec/cdi/pull/286</a><br>
> - I raised a PR <a href="https://github.com/cdi-spec/cdi/pull/289" target="_blank">https://github.com/cdi-spec/cdi/pull/289</a> to update the spec to clarify how to manage a dependent scoped bean.<br>
><br>
> Right now, it seems that the big disagreement is whether Instance.destroy() can destroy objects not created by it (the case being around the CDI utility class, being an impl of Instance). I'm currently heavily against Martin's proposed changes, but want to get input from others on the group to understand their perspective.<br>
><br>
> - Does the spec require destroy() to be called only on instances that it created? When I read 5.6.1 the only requirement I see is that it has to be a dependent scoped bean. Note when I ask this I'm asking from the spec perspective, its a different problem if there's some issues with implementations following suite (I would imagine there needs to be some shared global registry of dependent scoped beans for this to work).<br>
></p>
<p dir="ltr">Sound the only clean impl. Any other is not symmetric and potentially lead to "oops this time it didnt work". I also not seeing any use case limitation with that so think it is the same solution<br></p></blockquote><div><br></div><div>I'm not sure I follow or if this isn't an answer to "Does the spec require destroy() to be called only on instances that it created?" ?</div><div><br></div><div>Anyways I did look a bit closer and it seems that Martin's statement is consistent with how OWB works, <a href="https://github.com/apache/openwebbeans/blob/trunk/webbeans-impl/src/main/java/org/apache/webbeans/inject/instance/InstanceImpl.java#L293">https://github.com/apache/openwebbeans/blob/trunk/webbeans-impl/src/main/java/org/apache/webbeans/inject/instance/InstanceImpl.java#L293</a> so I wonder if there's a part of the spec I'm missing, or if there was some offline agreement on how to understand it.</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"><p dir="ltr"></p>
<p dir="ltr"></p><p dir="ltr">> - Do we want two methods that effectively do the same thing? I don't see a strong difference between the two.<br>
><br>
> On the flipside, my change is more a spec clarification. I'm thinking more now that it belongs as a reword of 5.6.1 to clarify how to use destroy() on dependent beans, rather than where I put it. I think realistically we have all of the tools needed to manage the lifecycle of these classes, just need to clarify them for people to use.<br>
><br>
> John<br>
><br></p><p dir="ltr">
> _______________________________________________<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" 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" 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>
</p>
</blockquote></div></div>