[cdi-dev] Managing Dependent Scoped Beans
Martin Kouba
mkouba at redhat.com
Mon May 16 08:20:00 EDT 2016
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":
"* 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
More information about the cdi-dev
mailing list