[cdi-dev] Managing Dependent Scoped Beans
Martin Kouba
mkouba at redhat.com
Mon May 16 05:48:12 EDT 2016
Ok, what about something like this (names to be discussed): add a new
interface:
ManagedInstance<T> implements AutoCloseable {
T get();
}
and two new methods on Instance:
ManagedInstance getAndDestroy();
ManagedInstance getAndRelease();
The first one would return a ManagedInstance whose close() would always
call Instance.destroy(). The latter one - close() would only call
Instance.destroy() for @Dependent beans.
Just throwing ideas...
Dne 16.5.2016 v 11:23 Romain Manni-Bucau napsal(a):
> I agree with you bit also the default should be smoother. Just trying to
> have side by side 2 confusing methods.
>
> Like the AutoCloseable idea btw.
>
> Le 16 mai 2016 11:20, "Martin Kouba" <mkouba at redhat.com
> <mailto:mkouba at redhat.com>> a écrit :
>
> 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>
> <mailto: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>>
> >> <mailto: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>>>
> >> <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 <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>>>
> >> <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.
> >> > >
> >> >
> >> > --
> >> > 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>>>
> >> <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.
> >>
> >>
> >> --
> >> 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