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

Mon Mar 12 14:15:20 EDT 2012

Nor do I, however, I'm at a loss as well as to where best to put this.

On Mon, Mar 12, 2012 at 12:12, Pete Muir <pmuir at redhat.com> wrote:

> Yeah, we could create a new class I guess, I don't love it though…
>
> On 12 Mar 2012, at 18:10, Jason Porter wrote:
>
> > 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/a222ecb1/attachment.html 