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

Marek Schmidt maschmid at redhat.com
Fri Mar 9 12:37:24 EST 2012


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



More information about the cdi-dev mailing list