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