[cdi-dev] Managing Dependent Scoped Beans

Martin Kouba mkouba at redhat.com
Mon May 16 05:20:20 EDT 2016


Dne 16.5.2016 v 11:08 Romain Manni-Bucau napsal(a):
>
> Le 16 mai 2016 10:42, "Martin Kouba" <mkouba at redhat.com
> <mailto:mkouba at redhat.com>> a écrit :
>  >
>  >
>  >
>  > Dne 16.5.2016 v 10:36 Romain Manni-Bucau napsal(a):
>  >
>  >> I see, thks.
>  >>
>  >> I dont like having 2 methods with the same semantic there but agree the
>  >> default is misleading for such cases.
>  >>
>  >> 1. Cant we change the default? looks like current one can break apps if
>  >> misunderstood and not sure changing it is worse.
>  >
>  >
>  > I think we cannot due to backward compatibility.
>  >
>  >
>  >>
>  >> If not
>  >>
>  >> 2. Maybe we can type the returned type with a release method in the
>  >> instance  wrapper instead of enriching Instance API making it contextual
>  >> by nature?: w=instance...get();w.getValue().work();w.release(/*no
> param*/);
>  >
>  >
>  > Sorry, I don't get it. Do you want to change Instance.get() signature
> and return some kind of wrapper? A simple snippet might help.
>  >
>
> Yes get a method to have the wrapper to manage a single instance:
>
> @Inject Instance i;
>
> ...
>
> Wrapper w = i.getSelected();
> ...
> w.getValue().businessmetd();
> ...
> w.release();

Well, we could introduce a new wrapper and even make is AutoCloseable, 
e.g. something like discussed here: 
http://lists.jboss.org/pipermail/cdi-dev/2016-May/008241.html

But still you would have to distinguish between destroy() and release(). 
My original proposal was to allow a user to inspect the Bean metadata, 
see also https://issues.jboss.org/browse/CDI-515. But guys convinced me ;-)

>
>  >>
>  >> That is what most framework did finally to integrate with CDI so looks
>  >> natural.
>  >>
>  >> Le 16 mai 2016 10:23, "Martin Kouba" <mkouba at redhat.com
> <mailto:mkouba at redhat.com>
>  >> <mailto:mkouba at redhat.com <mailto:mkouba at redhat.com>>> a écrit :
>  >>
>  >>     Dne 16.5.2016 v 10:20 Romain Manni-Bucau napsal(a):
>  >>
>  >>
>  >>         Le 16 mai 2016 10:01, "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>>>> a écrit :
>  >>
>  >>           >
>  >>           > Dne 15.5.2016 v 16:14 John D. Ament napsal(a):
>  >>           > > 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).
>  >>           > >
>  >>           > > - Do we want two methods that effectively do the same
>  >>         thing?  I don't
>  >>           > > see a strong difference between the two.
>  >>           >
>  >>           > Instance.destroy() currently always destroys the contextual
>  >>         instance.
>  >>           > Which is not always what users expect. That's why I proposed
>  >>         to add
>  >>           > Instance.release() -
> https://github.com/cdi-spec/cdi/pull/286,
>  >>           > previously Instance.getBean() -
>  >> https://github.com/cdi-spec/cdi/pull/273.
>  >>           >
>  >>
>  >>         Since you give the instance to both I guess the intention
> from user
>  >>         point of view is obvious and then we dont need 2 methods. What
>  >>         would be
>  >>         the other use case?
>  >>
>  >>
>  >> https://github.com/cdi-spec/cdi/pull/273#issuecomment-179080614
>  >>
>  >>
>  >>           > >
>  >>           > > 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.
>  >>           > >
>  >>           >
>  >>           > --
>  >>           > Martin Kouba
>  >>           > Software Engineer
>  >>           > Red Hat, Czech Republic
>  >>           > _______________________________________________
>  >>           > 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


More information about the cdi-dev mailing list