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

Mon Mar 12 14:12:50 EDT 2012

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