[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