[cdi-dev] Managing Dependent Scoped Beans
John D. Ament
john.d.ament at gmail.com
Mon May 16 08:13:34 EDT 2016
Martin,
On Mon, May 16, 2016 at 8:06 AM Martin Kouba <mkouba at redhat.com> wrote:
>
> Dne 16.5.2016 v 13:34 John D. Ament napsal(a):
> >
> > Martin,
> >
> >
> > On Mon, May 16, 2016 at 3:54 AM Martin Kouba <mkouba at redhat.com
> > <mailto:mkouba at redhat.com>> wrote:
> >
> > Dne 15.5.2016 v 17:14 John D. Ament napsal(a):
> > > Romain,
> > >
> > > On Sun, May 15, 2016 at 11:05 AM Romain Manni-Bucau
> > > <rmannibucau at gmail.com <mailto:rmannibucau at gmail.com>
> > <mailto:rmannibucau at gmail.com <mailto:rmannibucau at gmail.com>>>
> wrote:
> > >
> > > Hi Jon
> > >
> > > Le 15 mai 2016 16:15, "John D. Ament" <john.d.ament at gmail.com
> > <mailto:john.d.ament at gmail.com>
> > > <mailto:john.d.ament at gmail.com
> > <mailto:john.d.ament at gmail.com>>> a écrit :
> > > >
> > > > Hey guys
> > > >
> > > > 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.
> > > >
> > > > - Martin raised a PR to add a release() method to Instance
> to
> > > help destroy a dependent bean
> > https://github.com/cdi-spec/cdi/pull/286
> > > > - I raised a PR https://github.com/cdi-spec/cdi/pull/289
> to
> > > update the spec to clarify how to manage a dependent scoped
> bean.
> > > >
> > > > 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.
> > > >
> > > > - 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).
> > > >
> > >
> > > 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
> > >
> > >
> > > 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?" ?
> > >
> > > Anyways I did look a bit closer and it seems that Martin's
> > statement is
> > > consistent with how OWB works,
> > >
> >
> https://github.com/apache/openwebbeans/blob/trunk/webbeans-impl/src/main/java/org/apache/webbeans/inject/instance/InstanceImpl.java#L293
> > 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.
> >
> > John, I believe Instance CANNOT be used to destroy a dependent bean
> > instance it didn't created, because a dependent bean instance doesn't
> > know the dependent objects it depends on - that's what
> CreationalContext
> > is for.
> >
> >
> > This is the area I'm looking for clarification around. Where in the
> > spec is this mandated?
>
> I think it's implied. When you look at "6.1.1. The CreationalContext
> interface", there is:
>
> "Contextual.create() should use the given CreationalContext when
> obtaining contextual references to inject, as defined in Contextual
> reference for a bean, in order to ensure that any dependent objects are
> associated with the contextual instance that is being created."
>
> and also:
>
> "Contextual.destroy() should call release() to allow the container to
> destroy dependent objects of the contextual instance."
>
> and "6.2. The Context interface":
>
> "The context object must pass the same instance of CreationalContext to
> Contextual.destroy() that it passed to Contextual.create() when it
> created the instance."
>
> And for dependent beans there is no real context which could hold a
> reference to a CreationalContext. Each Instance<T> has its own
> CreationalContext which only tracks the dependent instances produced by
> a given Instance. Instance<T> does not know anything about
> CreationalContexts of other dependent instances...
>
I think I'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's creating a bean.
Maybe something along the lines of
"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()"
I would still like us to explore ways to do this without requiring the
original instance, for the case of CDI.current() usage.
John
>
> >
> > So if you pass any dependent instance to Instance.destroy() there is
> no
> > CreationalContext apart from the one Instance<> has. In other words
> you
> > wouldn't be able to destroy the @Dependent dependencies of a
> @Dependent
> > bean instane. Does it make sense?
> >
> > See also https://issues.jboss.org/browse/CDI-519
> (cdi-spec/cdi/pull/278
> > is already merged).
> >
> >
> > >
> > > John
> > >
> > > > - Do we want two methods that effectively do the same
> > thing? I
> > > don't see a strong difference between the two.
> > > >
> > > > 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.
> > > >
> > > > John
> > > >
> > >
> > > > _______________________________________________
> > > > cdi-dev mailing list
> > > > cdi-dev at lists.jboss.org <mailto:cdi-dev at lists.jboss.org>
> > <mailto:cdi-dev at lists.jboss.org <mailto:cdi-dev at lists.jboss.org>>
> > > > https://lists.jboss.org/mailman/listinfo/cdi-dev
> > > >
> > > > Note that for all code provided on this list, the provider
> > > licenses the code under the Apache License, Version 2
> > > (http://www.apache.org/licenses/LICENSE-2.0.html). For all
> other
> > > ideas provided on this list, the provider waives all patent
> and
> > > other intellectual property rights inherent in such
> information.
> > >
> > >
> > >
> > > _______________________________________________
> > > cdi-dev mailing list
> > > cdi-dev at lists.jboss.org <mailto:cdi-dev at lists.jboss.org>
> > > https://lists.jboss.org/mailman/listinfo/cdi-dev
> > >
> > > Note that for all code provided on this list, the provider
> > licenses the code under the Apache License, Version 2
> > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other
> > ideas provided on this list, the provider waives all patent and
> > other intellectual property rights inherent in such information.
> > >
> >
> > --
> > Martin Kouba
> > Software Engineer
> > Red Hat, Czech Republic
> >
>
> --
> Martin Kouba
> Software Engineer
> Red Hat, Czech Republic
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160516/720e7668/attachment-0001.html
More information about the cdi-dev
mailing list