[cdi-dev] Managing Dependent Scoped Beans
John D. Ament
john.d.ament at gmail.com
Mon May 16 08:52:41 EDT 2016
On Mon, May 16, 2016 at 8:20 AM Martin Kouba <mkouba at redhat.com> wrote:
>
>
> Dne 16.5.2016 v 14:13 John D. Ament napsal(a):
> > Martin,
> >
> > On Mon, May 16, 2016 at 8:06 AM Martin Kouba <mkouba at redhat.com
> > <mailto: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>
> > > <mailto: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>>
> > > <mailto: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
> >>
> > > > <mailto: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.
>
> Well, I think it's implied as well: Instance<T> is a dependent bean and
> "6.4.1. Dependent objects":
>
That means Instance is dependent, not that the objects it creates are
dependent.
>
> "* An instance of a bean with scope @Dependent obtained by direct
> invocation of an Instance is a dependent object of the instance of
> Instance."
>
> So it's practically the same as injecting a @Dependent bean into another
> @Dependent 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>>
> > > <mailto: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>
> > <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.
> > > >
> > >
> > > --
> > > Martin Kouba
> > > Software Engineer
> > > Red Hat, Czech Republic
> > >
> >
> > --
> > 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/16a035ff/attachment-0001.html
More information about the cdi-dev
mailing list