I think we have to offer both options. One which in which @PreDestroy is reliably invoked but with memory impact, other in which it's not reliable. Which one should be the default? On 8 Mar 2012, at 12:47, Mark Struberg wrote: > My answer sadly is no. > > Dependent objects are stored in the CreationalContext which is held in the context which holds the outer NormalScoped contextual instance. > If the outer NormalScoped contextual instance gets desroyed, we also properly destroy all @Dependent beans in the CreationalContext. > > So far so good, but now let's consider hte following scenario: > > > @ApplicationScoped > public class MyService { > > void doStats(@Observes RequestStatistics, UserHelper uh) { > > UserHelper is @Dependent and a new instance will get created each time doStats() gets called. > > What happens is that we don't know whether the UserHelper internally gets stored or just thrown away. In our sample most probably the later. > Each UserHelper will get stored in the CreationalContext of our single MyService instance. After 500.000 requests, our CreationalContext would contain 500.000 UserHelpers. Not smart, eh? This would just create a fat memory leak... > > > What we can do is to store only WeakReferences. E.g. via a WeakHashmap. This will automatically drop the entries if the instances in it get garbage collected. But in this case are not able to invoke @PreDestroy anymore I fear, because gone is gone ... > > LieGrue, > strub > > > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev

I think you are wrong. The spec says: "Any instance of the bean injected into method parameters of a disposer method or observer method exists to service the method invocation only (except for observer methods of container lifecycle events)." So the instance should actually be destroyed immediately after the observer method invocation finishes. On 03/08/2012 01:47 PM, Mark Struberg wrote: > My answer sadly is no. > > Dependent objects are stored in the CreationalContext which is held in the context which holds the outer NormalScoped contextual instance. > If the outer NormalScoped contextual instance gets desroyed, we also properly destroy all @Dependent beans in the CreationalContext. > > So far so good, but now let's consider hte following scenario: > > > @ApplicationScoped > public class MyService { > > void doStats(@Observes RequestStatistics, UserHelper uh) { > > > UserHelper is @Dependent and a new instance will get created each time doStats() gets called. > > What happens is that we don't know whether the UserHelper internally gets stored or just thrown away. In our sample most probably the later. > Each UserHelper will get stored in the CreationalContext of our single MyService instance. After 500.000 requests, our CreationalContext would contain 500.000 UserHelpers. Not smart, eh? This would just create a fat memory leak... > > > What we can do is to store only WeakReferences. E.g. via a WeakHashmap. This will automatically drop the entries if the instances in it get garbage collected. But in this case are not able to invoke @PreDestroy anymore I fear, because gone is gone ... > > LieGrue, > strub > > > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev

I think you are wrong. The spec says: "Any instance of the bean injected into method parameters of a disposer method or observer method exists to service the method invocation only (except for observer methods of container lifecycle events)." So the instance should actually be destroyed immediately after the observer method invocation finishes. On 03/08/2012 01:47 PM, Mark Struberg wrote: > My answer sadly is no. > > Dependent objects are stored in the CreationalContext which is held in the context which holds the outer NormalScoped contextual instance. > If the outer NormalScoped contextual instance gets desroyed, we also properly destroy all @Dependent beans in the CreationalContext. > > So far so good, but now let's consider hte following scenario: > > > @ApplicationScoped > public class MyService { > > void doStats(@Observes RequestStatistics, UserHelper uh) { > > > UserHelper is @Dependent and a new instance will get created each time doStats() gets called. > > What happens is that we don't know whether the UserHelper internally gets stored or just thrown away. In our sample most probably the later. > Each UserHelper will get stored in the CreationalContext of our single MyService instance. After 500.000 requests, our CreationalContext would contain 500.000 UserHelpers. Not smart, eh? This would just create a fat memory leak... > > > What we can do is to store only WeakReferences. E.g. via a WeakHashmap. This will automatically drop the entries if the instances in it get garbage collected. But in this case are not able to invoke @PreDestroy anymore I fear, because gone is gone ... > > LieGrue, > strub > > > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev

Well, I think the newly proposed wording is still fine (sharing the CreationalContext of the @Dependent beans created by Instance.get() with the InjectionPoint. What we need to do is to point people at manually creating the beans if they don't like this behaviour. In that case they still can use BeanManager#getBeans + bm#resolve + bm#getReference storing away the CreationalContext and later throw them away manually with bean.destroy. LieGrue, strub ----- Original Message ----- > From: Pete Muir <pmuir(a)redhat.com&gt; > To: Jozef Hartinger <jharting(a)redhat.com&gt; > Cc: Mark Struberg <struberg(a)yahoo.de>; cdi-dev <cdi-dev(a)lists.jboss.org&gt; > Sent: Thursday, March 8, 2012 11:35 PM > Subject: Re: [cdi-dev] Are we always able to invoke @PreDestroy for @Dependent beans? > > T his is still an issue for Instance.get() :-( > > On 8 Mar 2012, at 15:47, Jozef Hartinger wrote: > >> I think you are wrong. The spec says: >> >> "Any instance of the bean injected into method parameters of a > disposer >> method or observer method exists to service the >> method invocation only (except for observer methods of container >> lifecycle events)." >> >> So the instance should actually be destroyed immediately after the >> observer method invocation finishes. >> >> On 03/08/2012 01:47 PM, Mark Struberg wrote: >>> My answer sadly is no. >>> >>> Dependent objects are stored in the CreationalContext which is held in > the context which holds the outer NormalScoped contextual instance. >>> If the outer NormalScoped contextual instance gets desroyed, we also > properly destroy all @Dependent beans in the CreationalContext. >>> >>> So far so good, but now let's consider hte following scenario: >>> >>> >>> @ApplicationScoped >>> public class MyService { >>> >>> void doStats(@Observes RequestStatistics, UserHelper uh) { >>> >>> >>> UserHelper is @Dependent and a new instance will get created each time > doStats() gets called. >>> >>> What happens is that we don't know whether the UserHelper > internally gets stored or just thrown away. In our sample most probably the > later. >>> Each UserHelper will get stored in the CreationalContext of our single > MyService instance. After 500.000 requests, our CreationalContext would contain > 500.000 UserHelpers. Not smart, eh? This would just create a fat memory leak... >>> >>> >>> What we can do is to store only WeakReferences. E.g. via a WeakHashmap. > This will automatically drop the entries if the instances in it get garbage > collected. But in this case are not able to invoke @PreDestroy anymore I fear, > because gone is gone ... >>> >>> LieGrue, >>> strub >>> >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >

From: Marek Schmidt <maschmid(a)redhat.com&gt; To: cdi-dev(a)lists.jboss.org Cc: Sent: Friday, March 9, 2012 6:37 PM Subject: Re: [cdi-dev] Are we always able to invoke @PreDestroy for @Dependent beans? On 09/03/12 17:47, Pete Muir wrote: > I would propose we add Instance.destroy() as well, to make it easier… and what would happen if the bean is not @Dependent? (I would think it should be no-op for those, as otherwise I would need to start caring about the scope of the bean I am injecting via Instance.get()... but then, such API would probably be a bit confusing... -- Marek Schmidt > > On 9 Mar 2012, at 16:45, Mark Struberg wrote: > >> Well, I think the newly proposed wording is still fine (sharing the CreationalContext of the @Dependent beans created by Instance.get() with the InjectionPoint. >> >> >> What we need to do is to point people at manually creating the beans if they don't like this behaviour. >> In that case they still can use >> BeanManager#getBeans + bm#resolve + bm#getReference >> storing away the CreationalContext and later throw them away manually with bean.destroy. >> >> >> LieGrue, >> strub >> >> >> ----- Original Message ----- >>> From: Pete Muir <pmuir(a)redhat.com&gt; >>> To: Jozef Hartinger <jharting(a)redhat.com&gt; >>> Cc: Mark Struberg <struberg(a)yahoo.de>; cdi-dev <cdi-dev(a)lists.jboss.org&gt; >>> Sent: Thursday, March 8, 2012 11:35 PM >>> Subject: Re: [cdi-dev] Are we always able to invoke @PreDestroy for @Dependent beans? >>> >>> T his is still an issue for Instance.get() :-( >>> >>> On 8 Mar 2012, at 15:47, Jozef Hartinger wrote: >>> >>>> I think you are wrong. The spec says: >>>> >>>> "Any instance of the bean injected into method parameters of a >>> disposer >>>> method or observer method exists to service the >>>> method invocation only (except for observer methods of container >>>> lifecycle events)." >>>> >>>> So the instance should actually be destroyed immediately after the >>>> observer method invocation finishes. >>>> >>>> On 03/08/2012 01:47 PM, Mark Struberg wrote: >>>>> My answer sadly is no. >>>>> >>>>> Dependent objects are stored in the CreationalContext which is held in >>> the context which holds the outer NormalScoped contextual instance. >>>>> If the outer NormalScoped contextual instance gets desroyed, we also >>> properly destroy all @Dependent beans in the CreationalContext. >>>>> >>>>> So far so good, but now let's consider hte following scenario: >>>>> >>>>> >>>>> @ApplicationScoped >>>>> public class MyService { >>>>> >>>>>     void doStats(@Observes RequestStatistics, UserHelper uh) { >>>>> >>>>> >>>>> UserHelper is @Dependent and a new instance will get created each time >>> doStats() gets called. >>>>> >>>>> What happens is that we don't know whether the UserHelper >>> internally gets stored or just thrown away. In our sample most probably the >>> later. >>>>> Each UserHelper will get stored in the CreationalContext of our single >>> MyService instance. After 500.000 requests, our CreationalContext would contain >>> 500.000 UserHelpers. Not smart, eh? This would just create a fat memory leak... >>>>> >>>>> >>>>> What we can do is to store only WeakReferences. E.g. via a WeakHashmap. >>> This will automatically drop the entries if the instances in it get garbage >>> collected. But in this case are not able to invoke @PreDestroy anymore I fear, >>> because gone is gone ... >>>>> >>>>> LieGrue, >>>>> strub >>>>> >>>>> >>>>> _______________________________________________ >>>>> cdi-dev mailing list >>>>> cdi-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> _______________________________________________ >>>> cdi-dev mailing list >>>> cdi-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>> > > > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev

We could do that, BUT we would still want to offer a convenient API for people to destroy beans. I think Marek is right, adding this to Instance isn't ideal. Any ideas about where a better place to put this? Simple API on BeanManager? :-/ On 9 Mar 2012, at 19:43, Mark Struberg wrote: > Not sure about the Instance#destroy() this might lead to a bunch of other problems... > What about an additional Annotation to differentiate between beans which should get tracked and ones who should not? > > ... still trying to get the whole picture ... > > LieGrue, > strub > > > > ----- Original Message ----- >> From: Marek Schmidt <maschmid(a)redhat.com&gt; >> To: cdi-dev(a)lists.jboss.org >> Cc: >> Sent: Friday, March 9, 2012 6:37 PM >> Subject: Re: [cdi-dev] Are we always able to invoke @PreDestroy for @Dependent beans? >> >> On 09/03/12 17:47, Pete Muir wrote: >>> I would propose we add Instance.destroy() as well, to make it easier… >> >> and what would happen if the bean is not @Dependent? (I would think it >> should be no-op for those, as otherwise I would need to start caring >> about the scope of the bean I am injecting via Instance.get()... but >> then, such API would probably be a bit confusing... >> >> -- >> Marek Schmidt >> >>> >>> On 9 Mar 2012, at 16:45, Mark Struberg wrote: >>> >>>> Well, I think the newly proposed wording is still fine (sharing the >> CreationalContext of the @Dependent beans created by Instance.get() with the >> InjectionPoint. >>>> >>>> >>>> What we need to do is to point people at manually creating the beans if >> they don't like this behaviour. >>>> In that case they still can use >>>> BeanManager#getBeans + bm#resolve + bm#getReference >>>> storing away the CreationalContext and later throw them away manually >> with bean.destroy. >>>> >>>> >>>> LieGrue, >>>> strub >>>> >>>> >>>> ----- Original Message ----- >>>>> From: Pete Muir <pmuir(a)redhat.com&gt; >>>>> To: Jozef Hartinger <jharting(a)redhat.com&gt; >>>>> Cc: Mark Struberg <struberg(a)yahoo.de>; cdi-dev >> <cdi-dev(a)lists.jboss.org&gt; >>>>> Sent: Thursday, March 8, 2012 11:35 PM >>>>> Subject: Re: [cdi-dev] Are we always able to invoke @PreDestroy for >> @Dependent beans? >>>>> >>>>> T his is still an issue for Instance.get() :-( >>>>> >>>>> On 8 Mar 2012, at 15:47, Jozef Hartinger wrote: >>>>> >>>>>> I think you are wrong. The spec says: >>>>>> >>>>>> "Any instance of the bean injected into method parameters >> of a >>>>> disposer >>>>>> method or observer method exists to service the >>>>>> method invocation only (except for observer methods of >> container >>>>>> lifecycle events)." >>>>>> >>>>>> So the instance should actually be destroyed immediately after >> the >>>>>> observer method invocation finishes. >>>>>> >>>>>> On 03/08/2012 01:47 PM, Mark Struberg wrote: >>>>>>> My answer sadly is no. >>>>>>> >>>>>>> Dependent objects are stored in the CreationalContext which >> is held in >>>>> the context which holds the outer NormalScoped contextual instance. >>>>>>> If the outer NormalScoped contextual instance gets >> desroyed, we also >>>>> properly destroy all @Dependent beans in the CreationalContext. >>>>>>> >>>>>>> So far so good, but now let's consider hte following >> scenario: >>>>>>> >>>>>>> >>>>>>> @ApplicationScoped >>>>>>> public class MyService { >>>>>>> >>>>>>> void doStats(@Observes RequestStatistics, UserHelper uh) >> { >>>>>>> >>>>>>> >>>>>>> UserHelper is @Dependent and a new instance will get >> created each time >>>>> doStats() gets called. >>>>>>> >>>>>>> What happens is that we don't know whether the >> UserHelper >>>>> internally gets stored or just thrown away. In our sample most >> probably the >>>>> later. >>>>>>> Each UserHelper will get stored in the CreationalContext of >> our single >>>>> MyService instance. After 500.000 requests, our CreationalContext >> would contain >>>>> 500.000 UserHelpers. Not smart, eh? This would just create a fat >> memory leak... >>>>>>> >>>>>>> >>>>>>> What we can do is to store only WeakReferences. E.g. via a >> WeakHashmap. >>>>> This will automatically drop the entries if the instances in it get >> garbage >>>>> collected. But in this case are not able to invoke @PreDestroy >> anymore I fear, >>>>> because gone is gone ... >>>>>>> >>>>>>> LieGrue, >>>>>>> strub >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> cdi-dev mailing list >>>>>>> cdi-dev(a)lists.jboss.org >>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>> _______________________________________________ >>>>>> cdi-dev mailing list >>>>>> cdi-dev(a)lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>> >>> >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> _______________________________________________ >> cdi-dev mailing list >> cdi-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/cdi-dev >> > > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev _______________________________________________ cdi-dev mailing list cdi-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/cdi-dev

Yeah, we could create a new class I guess, I don't love it though… On 12 Mar 2012, at 18:10, Jason Porter wrote: > I don't have a solution, but BeanManager doesn't seem like the correct location either. Instance is part of a user facing API, BeanManager wasn't really supposed to be part of a standard user API. > > Do we create another class, like a utility class called BeanDestroyer or something? Seems like javax.inject.Provider should have a destroy on it :( > > If there isn't a good place for it, I guess BeanManager would work just as well. > > On Mon, Mar 12, 2012 at 11:57, Pete Muir <pmuir(a)redhat.com&gt; wrote: > We could do that, BUT we would still want to offer a convenient API for people to destroy beans. I think Marek is right, adding this to Instance isn't ideal. Any ideas about where a better place to put this? Simple API on BeanManager? :-/ > > On 9 Mar 2012, at 19:43, Mark Struberg wrote: > > > Not sure about the Instance#destroy() this might lead to a bunch of other problems... > > What about an additional Annotation to differentiate between beans which should get tracked and ones who should not? > > > > ... still trying to get the whole picture ... > > > > LieGrue, > > strub > > > > > > > > ----- Original Message ----- > >> From: Marek Schmidt <maschmid(a)redhat.com&gt; > >> To: cdi-dev(a)lists.jboss.org > >> Cc: > >> Sent: Friday, March 9, 2012 6:37 PM > >> Subject: Re: [cdi-dev] Are we always able to invoke @PreDestroy for @Dependent beans? > >> > >> On 09/03/12 17:47, Pete Muir wrote: > >>> I would propose we add Instance.destroy() as well, to make it easier… > >> > >> and what would happen if the bean is not @Dependent? (I would think it > >> should be no-op for those, as otherwise I would need to start caring > >> about the scope of the bean I am injecting via Instance.get()... but > >> then, such API would probably be a bit confusing... > >> > >> -- > >> Marek Schmidt > >> > >>> > >>> On 9 Mar 2012, at 16:45, Mark Struberg wrote: > >>> > >>>> Well, I think the newly proposed wording is still fine (sharing the > >> CreationalContext of the @Dependent beans created by Instance.get() with the > >> InjectionPoint. > >>>> > >>>> > >>>> What we need to do is to point people at manually creating the beans if > >> they don't like this behaviour. > >>>> In that case they still can use > >>>> BeanManager#getBeans + bm#resolve + bm#getReference > >>>> storing away the CreationalContext and later throw them away manually > >> with bean.destroy. > >>>> > >>>> > >>>> LieGrue, > >>>> strub > >>>> > >>>> > >>>> ----- Original Message ----- > >>>>> From: Pete Muir <pmuir(a)redhat.com&gt; > >>>>> To: Jozef Hartinger <jharting(a)redhat.com&gt; > >>>>> Cc: Mark Struberg <struberg(a)yahoo.de>; cdi-dev > >> <cdi-dev(a)lists.jboss.org&gt; > >>>>> Sent: Thursday, March 8, 2012 11:35 PM > >>>>> Subject: Re: [cdi-dev] Are we always able to invoke @PreDestroy for > >> @Dependent beans? > >>>>> > >>>>> T his is still an issue for Instance.get() :-( > >>>>> > >>>>> On 8 Mar 2012, at 15:47, Jozef Hartinger wrote: > >>>>> > >>>>>> I think you are wrong. The spec says: > >>>>>> > >>>>>> "Any instance of the bean injected into method parameters > >> of a > >>>>> disposer > >>>>>> method or observer method exists to service the > >>>>>> method invocation only (except for observer methods of > >> container > >>>>>> lifecycle events)." > >>>>>> > >>>>>> So the instance should actually be destroyed immediately after > >> the > >>>>>> observer method invocation finishes. > >>>>>> > >>>>>> On 03/08/2012 01:47 PM, Mark Struberg wrote: > >>>>>>> My answer sadly is no. > >>>>>>> > >>>>>>> Dependent objects are stored in the CreationalContext which > >> is held in > >>>>> the context which holds the outer NormalScoped contextual instance. > >>>>>>> If the outer NormalScoped contextual instance gets > >> desroyed, we also > >>>>> properly destroy all @Dependent beans in the CreationalContext. > >>>>>>> > >>>>>>> So far so good, but now let's consider hte following > >> scenario: > >>>>>>> > >>>>>>> > >>>>>>> @ApplicationScoped > >>>>>>> public class MyService { > >>>>>>> > >>>>>>> void doStats(@Observes RequestStatistics, UserHelper uh) > >> { > >>>>>>> > >>>>>>> > >>>>>>> UserHelper is @Dependent and a new instance will get > >> created each time > >>>>> doStats() gets called. > >>>>>>> > >>>>>>> What happens is that we don't know whether the > >> UserHelper > >>>>> internally gets stored or just thrown away. In our sample most > >> probably the > >>>>> later. > >>>>>>> Each UserHelper will get stored in the CreationalContext of > >> our single > >>>>> MyService instance. After 500.000 requests, our CreationalContext > >> would contain > >>>>> 500.000 UserHelpers. Not smart, eh? This would just create a fat > >> memory leak... > >>>>>>> > >>>>>>> > >>>>>>> What we can do is to store only WeakReferences. E.g. via a > >> WeakHashmap. > >>>>> This will automatically drop the entries if the instances in it get > >> garbage > >>>>> collected. But in this case are not able to invoke @PreDestroy > >> anymore I fear, > >>>>> because gone is gone ... > >>>>>>> > >>>>>>> LieGrue, > >>>>>>> strub > >>>>>>> > >>>>>>> > >>>>>>> _______________________________________________ > >>>>>>> cdi-dev mailing list > >>>>>>> cdi-dev(a)lists.jboss.org > >>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev > >>>>>> _______________________________________________ > >>>>>> cdi-dev mailing list > >>>>>> cdi-dev(a)lists.jboss.org > >>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev > >>>>> > >>> > >>> > >>> _______________________________________________ > >>> cdi-dev mailing list > >>> cdi-dev(a)lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/cdi-dev > >> > >> _______________________________________________ > >> cdi-dev mailing list > >> cdi-dev(a)lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/cdi-dev > >> > > > > _______________________________________________ > > cdi-dev mailing list > > cdi-dev(a)lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > _______________________________________________ > cdi-dev mailing list > cdi-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > > > -- > Jason Porter > http://lightguard-jp.blogspot.com > http://twitter.com/lightguardjp > > Software Engineer > Open Source Advocate > Author of Seam Catch - Next Generation Java Exception Handling > > PGP key id: 926CCFF5 > PGP key available at: keyserver.net, pgp.mit.edu

Folks, imo it's completely secondary _where_ we put this. The question for me is where we get the CreationalContext from! This must be stored somewhere and probably creates a mem leak in this location. And we need the CreationalContext to properly clean up the contextual instance as well... LieGrue, strub >________________________________ > From: Jason Porter <lightguard.jp(a)gmail.com&gt; >To: Pete Muir <pmuir(a)redhat.com&gt; >Cc: Mark Struberg <struberg(a)yahoo.de>; &quot;cdi-dev(a)lists.jboss.org&quot; < cdi-dev(a)lists.jboss.org&gt; >Sent: Monday, March 12, 2012 7:10 PM >Subject: Re: [cdi-dev] Are we always able to invoke @PreDestroy for @Dependent beans? > > >I don't have a solution, but BeanManager doesn't seem like the correct location either. Instance is part of a user facing API, BeanManager wasn't really supposed to be part of a standard user API. > > >Do we create another class, like a utility class called BeanDestroyer or something? Seems like javax.inject.Provider should have a destroy on it :( > > >If there isn't a good place for it, I guess BeanManager would work just as well. > > >On Mon, Mar 12, 2012 at 11:57, Pete Muir <pmuir(a)redhat.com&gt; wrote: > >We could do that, BUT we would still want to offer a convenient API for people to destroy beans. I think Marek is right, adding this to Instance isn't ideal. Any ideas about where a better place to put this? Simple API on BeanManager? :-/ >> >> >>On 9 Mar 2012, at 19:43, Mark Struberg wrote: >> >>> Not sure about the Instance#destroy() this might lead to a bunch of other problems... >>> What about an additional Annotation to differentiate between beans which should get tracked and ones who should not? >>> >>> ... still trying to get the whole picture ... >>> >>> LieGrue, >>> strub >>> >>> >>> >>> ----- Original Message ----- >>>> From: Marek Schmidt <maschmid(a)redhat.com&gt; >>>> To: cdi-dev(a)lists.jboss.org >>>> Cc: >>>> Sent: Friday, March 9, 2012 6:37 PM >>>> Subject: Re: [cdi-dev] Are we always able to invoke @PreDestroy for @Dependent beans? >>>> >>>> On 09/03/12 17:47, Pete Muir wrote: >>>>> I would propose we add Instance.destroy() as well, to make it easier… >>>> >>>> and what would happen if the bean is not @Dependent? (I would think it >>>> should be no-op for those, as otherwise I would need to start caring >>>> about the scope of the bean I am injecting via Instance.get()... but >>>> then, such API would probably be a bit confusing... >>>> >>>> -- >>>> Marek Schmidt >>>> >>>>> >>>>> On 9 Mar 2012, at 16:45, Mark Struberg wrote: >>>>> >>>>>> Well, I think the newly proposed wording is still fine (sharing the >>>> CreationalContext of the @Dependent beans created by Instance.get() with the >>>> InjectionPoint. >>>>>> >>>>>> >>>>>> What we need to do is to point people at manually creating the beans if >>>> they don't like this behaviour. >>>>>> In that case they still can use >>>>>> BeanManager#getBeans + bm#resolve + bm#getReference >>>>>> storing away the CreationalContext and later throw them away manually >>>> with bean.destroy. >>>>>> >>>>>> >>>>>> LieGrue, >>>>>> strub >>>>>> >>>>>> >>>>>> ----- Original Message ----- >>>>>>> From: Pete Muir <pmuir(a)redhat.com&gt; >>>>>>> To: Jozef Hartinger <jharting(a)redhat.com&gt; >>>>>>> Cc: Mark Struberg <struberg(a)yahoo.de>; cdi-dev >>>> <cdi-dev(a)lists.jboss.org&gt; >>>>>>> Sent: Thursday, March 8, 2012 11:35 PM >>>>>>> Subject: Re: [cdi-dev] Are we always able to invoke @PreDestroy for >>>> @Dependent beans? >>>>>>> >>>>>>> T his is still an issue for Instance.get() :-( >>>>>>> >>>>>>> On 8 Mar 2012, at 15:47, Jozef Hartinger wrote: >>>>>>> >>>>>>>> I think you are wrong. The spec says: >>>>>>>> >>>>>>>> "Any instance of the bean injected into method parameters >>>> of a >>>>>>> disposer >>>>>>>> method or observer method exists to service the >>>>>>>> method invocation only (except for observer methods of >>>> container >>>>>>>> lifecycle events)." >>>>>>>> >>>>>>>> So the instance should actually be destroyed immediately after >>>> the >>>>>>>> observer method invocation finishes. >>>>>>>> >>>>>>>> On 03/08/2012 01:47 PM, Mark Struberg wrote: >>>>>>>>> My answer sadly is no. >>>>>>>>> >>>>>>>>> Dependent objects are stored in the CreationalContext which >>>> is held in >>>>>>> the context which holds the outer NormalScoped contextual instance. >>>>>>>>> If the outer NormalScoped contextual instance gets >>>> desroyed, we also >>>>>>> properly destroy all @Dependent beans in the CreationalContext. >>>>>>>>> >>>>>>>>> So far so good, but now let's consider hte following >>>> scenario: >>>>>>>>> >>>>>>>>> >>>>>>>>> @ApplicationScoped >>>>>>>>> public class MyService { >>>>>>>>> >>>>>>>>> void doStats(@Observes RequestStatistics, UserHelper uh) >>>> { >>>>>>>>> >>>>>>>>> >>>>>>>>> UserHelper is @Dependent and a new instance will get >>>> created each time >>>>>>> doStats() gets called. >>>>>>>>> >>>>>>>>> What happens is that we don't know whether the >>>> UserHelper >>>>>>> internally gets stored or just thrown away. In our sample most >>>> probably the >>>>>>> later. >>>>>>>>> Each UserHelper will get stored in the CreationalContext of >>>> our single >>>>>>> MyService instance. After 500.000 requests, our CreationalContext >>>> would contain >>>>>>> 500.000 UserHelpers. Not smart, eh? This would just create a fat >>>> memory leak... >>>>>>>>> >>>>>>>>> >>>>>>>>> What we can do is to store only WeakReferences. E.g. via a >>>> WeakHashmap. >>>>>>> This will automatically drop the entries if the instances in it get >>>> garbage >>>>>>> collected. But in this case are not able to invoke @PreDestroy >>>> anymore I fear, >>>>>>> because gone is gone ... >>>>>>>>> >>>>>>>>> LieGrue, >>>>>>>>> strub >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> cdi-dev mailing list >>>>>>>>> cdi-dev(a)lists.jboss.org >>>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>>>> _______________________________________________ >>>>>>>> cdi-dev mailing list >>>>>>>> cdi-dev(a)lists.jboss.org >>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> cdi-dev mailing list >>>>> cdi-dev(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>>> _______________________________________________ >>>> cdi-dev mailing list >>>> cdi-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/cdi-dev >>>> >>> >>> _______________________________________________ >>> cdi-dev mailing list >>> cdi-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/cdi-dev >> >> >>_______________________________________________ >>cdi-dev mailing list &gt;&gt;cdi-dev(a)lists.jboss.org >>https://lists.jboss.org/mailman/listinfo/cdi-dev >> > > > >-- >Jason Porter >http://lightguard-jp.blogspot.com >http://twitter.com/lightguardjp > >Software Engineer >Open Source Advocate >Author of Seam Catch - Next Generation Java Exception Handling > >PGP key id: 926CCFF5 >PGP key available at: keyserver.net, pgp.mit.edu > > >