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