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

Mon Mar 12 14:56:06 EDT 2012

In that case, could we simply add a getCreationalContext() to Instance? Or
similar, maybe a simplified context?

On Mon, Mar 12, 2012 at 12:44, Mark Struberg <struberg at yahoo.de> wrote:

> 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
> >
> >
> >
>

-- 
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/cdi-dev/attachments/20120312/6c362464/attachment.html 