<p dir="ltr">I see, thks. </p>
<p dir="ltr">I dont like having 2 methods with the same semantic there but agree the default is misleading for such cases.</p>
<p dir="ltr">1. Cant we change the default? looks like current one can break apps if misunderstood and not sure changing it is worse.</p>
<p dir="ltr">If not</p>
<p dir="ltr">2. Maybe we can type the returned type with a release method in the instance wrapper instead of enriching Instance API making it contextual by nature?: w=instance...get();w.getValue().work();w.release(/*no param*/);</p>
<p dir="ltr">That is what most framework did finally to integrate with CDI so looks natural.</p>
<div class="gmail_quote">Le 16 mai 2016 10:23, "Martin Kouba" <<a href="mailto:mkouba@redhat.com">mkouba@redhat.com</a>> a écrit :<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dne 16.5.2016 v 10:20 Romain Manni-Bucau napsal(a):<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Le 16 mai 2016 10:01, "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>>> a écrit :<br>
><br>
> Dne 15.5.2016 v 16:14 John D. Ament napsal(a):<br>
> > Hey guys<br>
> ><br>
> > Seems like we have some issues in JIRA all focused on managing the<br>
> > lifecycle of Dependent scoped beans. It also seems like we have many<br>
> > differing opinions about how to manage them.<br>
> ><br>
> > - Martin raised a PR to add a release() method to Instance to help<br>
> > destroy a dependent bean <a href="https://github.com/cdi-spec/cdi/pull/286" rel="noreferrer" 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" rel="noreferrer" target="_blank">https://github.com/cdi-spec/cdi/pull/289</a> to update the<br>
> > spec to clarify how to manage a dependent scoped bean.<br>
> ><br>
> > Right now, it seems that the big disagreement is whether<br>
> > Instance.destroy() can destroy objects not created by it (the case<br>
being<br>
> > around the CDI utility class, being an impl of Instance). I'm<br>
currently<br>
> > heavily against Martin's proposed changes, but want to get input from<br>
> > others on the group to understand their perspective.<br>
> ><br>
> > - Does the spec require destroy() to be called only on instances<br>
that it<br>
> > created? When I read 5.6.1 the only requirement I see is that it<br>
has to<br>
> > be a dependent scoped bean. Note when I ask this I'm asking from the<br>
> > spec perspective, its a different problem if there's some issues with<br>
> > implementations following suite (I would imagine there needs to be some<br>
> > shared global registry of dependent scoped beans for this to work).<br>
> ><br>
> > - Do we want two methods that effectively do the same thing? I don't<br>
> > see a strong difference between the two.<br>
><br>
> Instance.destroy() currently always destroys the contextual instance.<br>
> Which is not always what users expect. That's why I proposed to add<br>
> Instance.release() - <a href="https://github.com/cdi-spec/cdi/pull/286" rel="noreferrer" target="_blank">https://github.com/cdi-spec/cdi/pull/286</a>,<br>
> previously Instance.getBean() - <a href="https://github.com/cdi-spec/cdi/pull/273" rel="noreferrer" target="_blank">https://github.com/cdi-spec/cdi/pull/273</a>.<br>
><br>
<br>
Since you give the instance to both I guess the intention from user<br>
point of view is obvious and then we dont need 2 methods. What would be<br>
the other use case?<br>
</blockquote>
<br>
<a href="https://github.com/cdi-spec/cdi/pull/273#issuecomment-179080614" rel="noreferrer" target="_blank">https://github.com/cdi-spec/cdi/pull/273#issuecomment-179080614</a><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> ><br>
> > On the flipside, my change is more a spec clarification. I'm thinking<br>
> > more now that it belongs as a reword of 5.6.1 to clarify how to use<br>
> > destroy() on dependent beans, rather than where I put it. I think<br>
> > realistically we have all of the tools needed to manage the<br>
lifecycle of<br>
> > these classes, just need to clarify them for people to use.<br>
> ><br>
> > John<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>
> > <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<br>
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 all other ideas<br>
provided on this list, the provider waives all patent and other<br>
intellectual property rights inherent in such information.<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> <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, the provider licenses<br>
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 all other ideas<br>
provided on this list, the provider waives all patent and other<br>
intellectual property rights inherent in such information.<br>
<br>
</blockquote>
<br>
-- <br>
Martin Kouba<br>
Software Engineer<br>
Red Hat, Czech Republic<br>
</blockquote></div>