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>
To: Pete Muir <pmuir(a)redhat.com>
Cc: Mark Struberg <struberg(a)yahoo.de>; "cdi-dev(a)lists.jboss.org"
<cdi-dev(a)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(a)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(a)redhat.com>
>>> 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>
>>>>>> To: Jozef Hartinger <jharting(a)redhat.com>
>>>>>> Cc: Mark Struberg <struberg(a)yahoo.de>; cdi-dev
>>> <cdi-dev(a)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(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