[cdi-dev] Managing Dependent Scoped Beans

Martin Kouba mkouba at redhat.com
Mon May 16 09:02:38 EDT 2016



Dne 16.5.2016 v 14:52 John D. Ament napsal(a):
>
>
> On Mon, May 16, 2016 at 8:20 AM Martin Kouba <mkouba at redhat.com
> <mailto: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>
>      > <mailto: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>>
>      >      > <mailto: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>>>
>      >      >     <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 <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>>>
>      >      >      >     <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
>     <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.

Defintely not. Read it again please. Built-in bean instance is 
@Dependent. And instance of a bean with scope @Dependent obtained by 
direct invocation of an Instance, ie. Instance.get()...

>
>
>     "* 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>>>
>      >      >     <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
>     <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>>
>      >     <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.
>      >      >      >
>      >      >
>      >      >     --
>      >      >     Martin Kouba
>      >      >     Software Engineer
>      >      >     Red Hat, Czech Republic
>      >      >
>      >
>      >     --
>      >     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