[cdi-dev] Managing Dependent Scoped Beans
Romain Manni-Bucau
rmannibucau at gmail.com
Mon May 16 06:12:14 EDT 2016
getInstanceHandler()? +1 for the idea
Le 16 mai 2016 11:48, "Martin Kouba" <mkouba at redhat.com> a écrit :
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20160516/f5d50279/attachment-0001.html
More information about the cdi-dev
mailing list