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

Mon Mar 12 14:10:13 EDT 2012

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