Nor do I, however, I'm at a loss as well as to where best to put this.<br><br><div class="gmail_quote">On Mon, Mar 12, 2012 at 12:12, Pete Muir <span dir="ltr"><<a href="mailto:pmuir@redhat.com">pmuir@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Yeah, we could create a new class I guess, I don't love it though…<br>
<div class="HOEnZb"><div class="h5"><br>
On 12 Mar 2012, at 18:10, Jason Porter wrote:<br>
<br>
> 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.<br>
><br>
> Do we create another class, like a utility class called BeanDestroyer or something? Seems like javax.inject.Provider should have a destroy on it :(<br>
><br>
> If there isn't a good place for it, I guess BeanManager would work just as well.<br>
><br>
> On Mon, Mar 12, 2012 at 11:57, Pete Muir <<a href="mailto:pmuir@redhat.com">pmuir@redhat.com</a>> wrote:<br>
> 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? :-/<br>
><br>
> On 9 Mar 2012, at 19:43, Mark Struberg wrote:<br>
><br>
> > Not sure about the Instance#destroy() this might lead to a bunch of other problems...<br>
> > What about an additional Annotation to differentiate between beans which should get tracked and ones who should not?<br>
> ><br>
> > ... still trying to get the whole picture ...<br>
> ><br>
> > LieGrue,<br>
> > strub<br>
> ><br>
> ><br>
> ><br>
> > ----- Original Message -----<br>
> >> From: Marek Schmidt <<a href="mailto:maschmid@redhat.com">maschmid@redhat.com</a>><br>
> >> To: <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
> >> Cc:<br>
> >> Sent: Friday, March 9, 2012 6:37 PM<br>
> >> Subject: Re: [cdi-dev] Are we always able to invoke @PreDestroy for @Dependent beans?<br>
> >><br>
> >> On 09/03/12 17:47, Pete Muir wrote:<br>
> >>> I would propose we add Instance.destroy() as well, to make it easier…<br>
> >><br>
> >> and what would happen if the bean is not @Dependent? (I would think it<br>
> >> should be no-op for those, as otherwise I would need to start caring<br>
> >> about the scope of the bean I am injecting via Instance.get()... but<br>
> >> then, such API would probably be a bit confusing...<br>
> >><br>
> >> --<br>
> >> Marek Schmidt<br>
> >><br>
> >>><br>
> >>> On 9 Mar 2012, at 16:45, Mark Struberg wrote:<br>
> >>><br>
> >>>> Well, I think the newly proposed wording is still fine (sharing the<br>
> >> CreationalContext of the @Dependent beans created by Instance.get() with the<br>
> >> InjectionPoint.<br>
> >>>><br>
> >>>><br>
> >>>> What we need to do is to point people at manually creating the beans if<br>
> >> they don't like this behaviour.<br>
> >>>> In that case they still can use<br>
> >>>> BeanManager#getBeans + bm#resolve + bm#getReference<br>
> >>>> storing away the CreationalContext and later throw them away manually<br>
> >> with bean.destroy.<br>
> >>>><br>
> >>>><br>
> >>>> LieGrue,<br>
> >>>> strub<br>
> >>>><br>
> >>>><br>
> >>>> ----- Original Message -----<br>
> >>>>> From: Pete Muir <<a href="mailto:pmuir@redhat.com">pmuir@redhat.com</a>><br>
> >>>>> To: Jozef Hartinger <<a href="mailto:jharting@redhat.com">jharting@redhat.com</a>><br>
> >>>>> Cc: Mark Struberg <<a href="mailto:struberg@yahoo.de">struberg@yahoo.de</a>>; cdi-dev<br>
> >> <<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a>><br>
> >>>>> Sent: Thursday, March 8, 2012 11:35 PM<br>
> >>>>> Subject: Re: [cdi-dev] Are we always able to invoke @PreDestroy for<br>
> >> @Dependent beans?<br>
> >>>>><br>
> >>>>> T his is still an issue for Instance.get() :-(<br>
> >>>>><br>
> >>>>> On 8 Mar 2012, at 15:47, Jozef Hartinger wrote:<br>
> >>>>><br>
> >>>>>> I think you are wrong. The spec says:<br>
> >>>>>><br>
> >>>>>> "Any instance of the bean injected into method parameters<br>
> >> of a<br>
> >>>>> disposer<br>
> >>>>>> method or observer method exists to service the<br>
> >>>>>> method invocation only (except for observer methods of<br>
> >> container<br>
> >>>>>> lifecycle events)."<br>
> >>>>>><br>
> >>>>>> So the instance should actually be destroyed immediately after<br>
> >> the<br>
> >>>>>> observer method invocation finishes.<br>
> >>>>>><br>
> >>>>>> On 03/08/2012 01:47 PM, Mark Struberg wrote:<br>
> >>>>>>> My answer sadly is no.<br>
> >>>>>>><br>
> >>>>>>> Dependent objects are stored in the CreationalContext which<br>
> >> is held in<br>
> >>>>> the context which holds the outer NormalScoped contextual instance.<br>
> >>>>>>> If the outer NormalScoped contextual instance gets<br>
> >> desroyed, we also<br>
> >>>>> properly destroy all @Dependent beans in the CreationalContext.<br>
> >>>>>>><br>
> >>>>>>> So far so good, but now let's consider hte following<br>
> >> scenario:<br>
> >>>>>>><br>
> >>>>>>><br>
> >>>>>>> @ApplicationScoped<br>
> >>>>>>> public class MyService {<br>
> >>>>>>><br>
> >>>>>>> void doStats(@Observes RequestStatistics, UserHelper uh)<br>
> >> {<br>
> >>>>>>><br>
> >>>>>>><br>
> >>>>>>> UserHelper is @Dependent and a new instance will get<br>
> >> created each time<br>
> >>>>> doStats() gets called.<br>
> >>>>>>><br>
> >>>>>>> What happens is that we don't know whether the<br>
> >> UserHelper<br>
> >>>>> internally gets stored or just thrown away. In our sample most<br>
> >> probably the<br>
> >>>>> later.<br>
> >>>>>>> Each UserHelper will get stored in the CreationalContext of<br>
> >> our single<br>
> >>>>> MyService instance. After 500.000 requests, our CreationalContext<br>
> >> would contain<br>
> >>>>> 500.000 UserHelpers. Not smart, eh? This would just create a fat<br>
> >> memory leak...<br>
> >>>>>>><br>
> >>>>>>><br>
> >>>>>>> What we can do is to store only WeakReferences. E.g. via a<br>
> >> WeakHashmap.<br>
> >>>>> This will automatically drop the entries if the instances in it get<br>
> >> garbage<br>
> >>>>> collected. But in this case are not able to invoke @PreDestroy<br>
> >> anymore I fear,<br>
> >>>>> because gone is gone ...<br>
> >>>>>>><br>
> >>>>>>> LieGrue,<br>
> >>>>>>> strub<br>
> >>>>>>><br>
> >>>>>>><br>
> >>>>>>> _______________________________________________<br>
> >>>>>>> cdi-dev mailing list<br>
> >>>>>>> <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
> >>>>>>> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
> >>>>>> _______________________________________________<br>
> >>>>>> cdi-dev mailing list<br>
> >>>>>> <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
> >>>>>> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
> >>>>><br>
> >>><br>
> >>><br>
> >>> _______________________________________________<br>
> >>> cdi-dev mailing list<br>
> >>> <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
> >>> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
> >><br>
> >> _______________________________________________<br>
> >> cdi-dev mailing list<br>
> >> <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
> >> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
> >><br>
> ><br>
> > _______________________________________________<br>
> > cdi-dev mailing list<br>
> > <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
> > <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
><br>
><br>
> _______________________________________________<br>
> cdi-dev mailing list<br>
> <a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
><br>
><br>
><br>
> --<br>
> Jason Porter<br>
> <a href="http://lightguard-jp.blogspot.com" target="_blank">http://lightguard-jp.blogspot.com</a><br>
> <a href="http://twitter.com/lightguardjp" target="_blank">http://twitter.com/lightguardjp</a><br>
><br>
> Software Engineer<br>
> Open Source Advocate<br>
> Author of Seam Catch - Next Generation Java Exception Handling<br>
><br>
> PGP key id: 926CCFF5<br>
> PGP key available at: <a href="http://keyserver.net" target="_blank">keyserver.net</a>, <a href="http://pgp.mit.edu" target="_blank">pgp.mit.edu</a><br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Jason Porter<br><a href="http://lightguard-jp.blogspot.com" target="_blank">http://lightguard-jp.blogspot.com</a><br><a href="http://twitter.com/lightguardjp" target="_blank">http://twitter.com/lightguardjp</a><br>
<br>Software Engineer<br>Open Source Advocate<br>Author of Seam Catch - Next Generation Java Exception Handling<br><br>PGP key id: 926CCFF5<br>PGP key available at: <a href="http://keyserver.net" target="_blank">keyserver.net</a>, <a href="http://pgp.mit.edu" target="_blank">pgp.mit.edu</a><br>