getInstanceHandler()? +1 for the idea
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@redhat.com
<mailto:mkouba@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@redhat.com
<mailto:mkouba@redhat.com>
<mailto:mkouba@redhat.com <mailto:mkouba@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@redhat.com
<mailto:mkouba@redhat.com>
<mailto:mkouba@redhat.com <mailto:mkouba@redhat.com>>
>> <mailto:mkouba@redhat.com <mailto:mkouba@redhat.com>
<mailto:mkouba@redhat.com <mailto:mkouba@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@redhat.com <mailto:mkouba@redhat.com>
<mailto:mkouba@redhat.com <mailto:mkouba@redhat.com>>
>> <mailto:mkouba@redhat.com
<mailto:mkouba@redhat.com> <mailto:mkouba@redhat.com
<mailto:mkouba@redhat.com>>>
>> <mailto:mkouba@redhat.com
<mailto:mkouba@redhat.com> <mailto:mkouba@redhat.com
<mailto:mkouba@redhat.com>>
<mailto:mkouba@redhat.com <mailto:mkouba@redhat.com>
<mailto:mkouba@redhat.com <mailto:mkouba@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@lists.jboss.org
<mailto:cdi-dev@lists.jboss.org>
<mailto:cdi-dev@lists.jboss.org
<mailto:cdi-dev@lists.jboss.org>>
<mailto:cdi-dev@lists.jboss.org <mailto:cdi-dev@lists.jboss.org>
<mailto:cdi-dev@lists.jboss.org <mailto:cdi-dev@lists.jboss.org>>>
>> <mailto:cdi-dev@lists.jboss.org
<mailto:cdi-dev@lists.jboss.org>
<mailto:cdi-dev@lists.jboss.org
<mailto:cdi-dev@lists.jboss.org>>
<mailto:cdi-dev@lists.jboss.org <mailto:cdi-dev@lists.jboss.org>
<mailto:cdi-dev@lists.jboss.org <mailto:cdi-dev@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@lists.jboss.org
<mailto:cdi-dev@lists.jboss.org> <mailto:cdi-dev@lists.jboss.org
<mailto:cdi-dev@lists.jboss.org>>
<mailto:cdi-dev@lists.jboss.org <mailto:cdi-dev@lists.jboss.org>
<mailto:cdi-dev@lists.jboss.org <mailto:cdi-dev@lists.jboss.org>>>
>> <mailto:cdi-dev@lists.jboss.org
<mailto:cdi-dev@lists.jboss.org>
<mailto:cdi-dev@lists.jboss.org
<mailto:cdi-dev@lists.jboss.org>>
<mailto:cdi-dev@lists.jboss.org <mailto:cdi-dev@lists.jboss.org>
<mailto:cdi-dev@lists.jboss.org <mailto:cdi-dev@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