<p dir="ltr">getInstanceHandler()? +1 for the idea</p>
<div class="gmail_quote">Le 16 mai 2016 11:48, "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">Ok, what about something like this (names to be discussed): add a new interface:<br>
<br>
ManagedInstance<T> implements AutoCloseable {<br>
T get();<br>
}<br>
<br>
and two new methods on Instance:<br>
<br>
ManagedInstance getAndDestroy();<br>
ManagedInstance getAndRelease();<br>
<br>
The first one would return a ManagedInstance whose close() would always call Instance.destroy(). The latter one - close() would only call Instance.destroy() for @Dependent beans.<br>
<br>
Just throwing ideas...<br>
<br>
<br>
Dne 16.5.2016 v 11:23 Romain Manni-Bucau napsal(a):<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I agree with you bit also the default should be smoother. Just trying to<br>
have side by side 2 confusing methods.<br>
<br>
Like the AutoCloseable idea btw.<br>
<br>
Le 16 mai 2016 11:20, "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 16.5.2016 v 11:08 Romain Manni-Bucau napsal(a):<br>
<br>
<br>
Le 16 mai 2016 10:42, "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>
<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>>>> a écrit :<br>
><br>
><br>
><br>
> Dne 16.5.2016 v 10:36 Romain Manni-Bucau napsal(a):<br>
><br>
>> I see, thks.<br>
>><br>
>> I dont like having 2 methods with the same semantic there<br>
but agree the<br>
>> default is misleading for such cases.<br>
>><br>
>> 1. Cant we change the default? looks like current one can<br>
break apps if<br>
>> misunderstood and not sure changing it is worse.<br>
><br>
><br>
> I think we cannot due to backward compatibility.<br>
><br>
><br>
>><br>
>> If not<br>
>><br>
>> 2. Maybe we can type the returned type with a release<br>
method in the<br>
>> instance wrapper instead of enriching Instance API making<br>
it contextual<br>
>> by nature?:<br>
w=instance...get();w.getValue().work();w.release(/*no<br>
param*/);<br>
><br>
><br>
> Sorry, I don't get it. Do you want to change Instance.get()<br>
signature<br>
and return some kind of wrapper? A simple snippet might help.<br>
><br>
<br>
Yes get a method to have the wrapper to manage a single instance:<br>
<br>
@Inject Instance i;<br>
<br>
...<br>
<br>
Wrapper w = i.getSelected();<br>
...<br>
w.getValue().businessmetd();<br>
...<br>
w.release();<br>
<br>
<br>
Well, we could introduce a new wrapper and even make is<br>
AutoCloseable, e.g. something like discussed here:<br>
<a href="http://lists.jboss.org/pipermail/cdi-dev/2016-May/008241.html" rel="noreferrer" target="_blank">http://lists.jboss.org/pipermail/cdi-dev/2016-May/008241.html</a><br>
<br>
But still you would have to distinguish between destroy() and<br>
release(). My original proposal was to allow a user to inspect the<br>
Bean metadata, see also <a href="https://issues.jboss.org/browse/CDI-515" rel="noreferrer" target="_blank">https://issues.jboss.org/browse/CDI-515</a>. But<br>
guys convinced me ;-)<br>
<br>
<br>
>><br>
>> That is what most framework did finally to integrate with<br>
CDI so looks<br>
>> natural.<br>
>><br>
>> Le 16 mai 2016 10:23, "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>
<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>>>>> a écrit :<br>
>><br>
>> Dne 16.5.2016 v 10:20 Romain Manni-Bucau napsal(a):<br>
>><br>
>><br>
>> Le 16 mai 2016 10:01, "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><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>>>><br>
>> <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>>><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>>>>>> a écrit :<br>
>><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<br>
focused on<br>
>> managing the<br>
>> > > lifecycle of Dependent scoped beans. It also<br>
seems like<br>
>> we have many<br>
>> > > differing opinions about how to manage them.<br>
>> > ><br>
>> > > - Martin raised a PR to add a release()<br>
method to Instance<br>
>> to help<br>
>> > > destroy a dependent bean<br>
>> <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<br>
<a href="https://github.com/cdi-spec/cdi/pull/289" rel="noreferrer" target="_blank">https://github.com/cdi-spec/cdi/pull/289</a><br>
>> to update the<br>
>> > > spec to clarify how to manage a dependent<br>
scoped bean.<br>
>> > ><br>
>> > > Right now, it seems that the big disagreement<br>
is whether<br>
>> > > Instance.destroy() can destroy objects not<br>
created by it<br>
>> (the case<br>
>> being<br>
>> > > around the CDI utility class, being an impl of<br>
Instance). I'm<br>
>> currently<br>
>> > > heavily against Martin's proposed changes,<br>
but want to get<br>
>> input from<br>
>> > > others on the group to understand their<br>
perspective.<br>
>> > ><br>
>> > > - Does the spec require destroy() to be<br>
called only on<br>
>> instances<br>
>> that it<br>
>> > > created? When I read 5.6.1 the only<br>
requirement I see is<br>
>> that it<br>
>> has to<br>
>> > > be a dependent scoped bean. Note when I ask<br>
this I'm<br>
>> asking from the<br>
>> > > spec perspective, its a different problem if<br>
there's some<br>
>> issues with<br>
>> > > implementations following suite (I would<br>
imagine there<br>
>> needs to be some<br>
>> > > shared global registry of dependent scoped<br>
beans for this<br>
>> to work).<br>
>> > ><br>
>> > > - Do we want two methods that effectively do<br>
the same<br>
>> thing? I don't<br>
>> > > see a strong difference between the two.<br>
>> ><br>
>> > Instance.destroy() currently always destroys<br>
the contextual<br>
>> instance.<br>
>> > Which is not always what users expect. That's<br>
why I proposed<br>
>> to add<br>
>> > Instance.release() -<br>
<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() -<br>
>> <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<br>
intention<br>
from user<br>
>> point of view is obvious and then we dont need 2<br>
methods. What<br>
>> would be<br>
>> the other use case?<br>
>><br>
>><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>
>><br>
>> > ><br>
>> > > On the flipside, my change is more a spec<br>
clarification.<br>
>> I'm thinking<br>
>> > > more now that it belongs as a reword of 5.6.1<br>
to clarify<br>
>> how to use<br>
>> > > destroy() on dependent beans, rather than<br>
where I put it.<br>
>> I think<br>
>> > > realistically we have all of the tools needed to<br>
manage the<br>
>> lifecycle of<br>
>> > > these classes, just need to clarify them for<br>
people to<br>
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><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><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> <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>><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>>><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> <mailto:<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a>>>>><br>
>><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<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>).<br>
For all other<br>
>> ideas<br>
>> provided on this list, the provider waives all<br>
patent and other<br>
>> intellectual property rights inherent in such<br>
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><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> <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>><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>>><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> <mailto:<a href="mailto:cdi-dev@lists.jboss.org" target="_blank">cdi-dev@lists.jboss.org</a>>>>><br>
>><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<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>).<br>
For all other<br>
>> ideas<br>
>> provided on this list, the provider waives all<br>
patent and other<br>
>> 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>
> Martin Kouba<br>
> Software Engineer<br>
> Red Hat, Czech Republic<br>
<br>
<br>
--<br>
Martin Kouba<br>
Software Engineer<br>
Red Hat, Czech Republic<br>
<br>
</blockquote>
<br>
-- <br>
Martin Kouba<br>
Software Engineer<br>
Red Hat, Czech Republic<br>
</blockquote></div>