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@redhat.com>
>> To:
cdi-dev@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@redhat.com>
>>>>> To: Jozef Hartinger <
jharting@redhat.com>
>>>>> Cc: Mark Struberg <
struberg@yahoo.de>; cdi-dev
>> <
cdi-dev@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@lists.jboss.org
>>>>>>>
https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>> _______________________________________________
>>>>>> cdi-dev mailing list
>>>>>>
cdi-dev@lists.jboss.org
>>>>>>
https://lists.jboss.org/mailman/listinfo/cdi-dev
>>>>>
>>>
>>>
>>> _______________________________________________
>>> cdi-dev mailing list
>>>
cdi-dev@lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>> _______________________________________________
>> cdi-dev mailing list
>>
cdi-dev@lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/cdi-dev
>>
>
> _______________________________________________
> cdi-dev mailing list
>
cdi-dev@lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/cdi-dev
_______________________________________________
cdi-dev mailing list
cdi-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev