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

Mon Mar 12 14:44:15 EDT 2012

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 at gmail.com>
>To: Pete Muir <pmuir at redhat.com> 
>Cc: Mark Struberg <struberg at yahoo.de>; "cdi-dev at lists.jboss.org" <cdi-dev at lists.jboss.org> 
>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 at redhat.com> 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 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
>>
>>
>>_______________________________________________
>>cdi-dev mailing list
>>cdi-dev at 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
>
>
>