[cdi-dev] Are we always able to invoke @PreDestroy for @Dependent beans?

Pete Muir pmuir at redhat.com
Mon Mar 12 13:57:36 EDT 2012


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 at redhat.com>
>> To: cdi-dev at 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 at redhat.com>
>>>>> To: Jozef Hartinger <jharting at redhat.com>
>>>>> Cc: Mark Struberg <struberg at yahoo.de>; cdi-dev 
>> <cdi-dev at lists.jboss.org>
>>>>> 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 at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>> _______________________________________________
>>>>>> cdi-dev mailing list
>>>>>> cdi-dev at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>> 
>>> 
>>> 
>>> _______________________________________________
>>> cdi-dev mailing list
>>> cdi-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>> 
>> _______________________________________________
>> cdi-dev mailing list
>> cdi-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/cdi-dev
>> 
> 
> _______________________________________________
> cdi-dev mailing list
> cdi-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev




More information about the cdi-dev mailing list