Well issue before was release was not bound to the created instance but znclosing class. Cdi 1.1 fixed it and now created instances can have their own lifecycle and be handled by themselves. A bit like what Unmanaged allows.
@Inject Instance<A> a; A inst = a.get(); a.destroy(inst); Le 28 févr. 2015 17:56, "Lars-Fredrik Smedberg" <[email protected]> a écrit : > @Romain maybe I'm slow today (i am on vacation :-)) do u mind explain with > an example? > On Feb 28, 2015 5:44 PM, "Romain Manni-Bucau" <[email protected]> > wrote: > >> It call release on the instance creational context and each instance has >> a child creational context of the parent. Said otherwise it is as if the >> bean as a scope handled manually >> Le 28 févr. 2015 17:32, "Lars-Fredrik Smedberg" <[email protected]> a >> écrit : >> >>> @Romain >>> >>> Can explain to me what difference it will make (what the fix does) >>> On Feb 28, 2015 3:49 PM, "Romain Manni-Bucau" <[email protected]> >>> wrote: >>> >>>> PS: to be complete CDI 1.x, x > 0 added destroy(X) in Instance API to >>>> fix it >>>> >>>> >>>> Romain Manni-Bucau >>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog >>>> <http://rmannibucau.wordpress.com> | Github >>>> <https://github.com/rmannibucau> | LinkedIn >>>> <https://www.linkedin.com/in/rmannibucau> | Tomitriber >>>> <http://www.tomitribe.com> >>>> >>>> 2015-02-28 11:20 GMT+01:00 Karl Kildén <[email protected]>: >>>> >>>>> Got it, thanks all! >>>>> >>>>> On 27 February 2015 at 19:54, John D. Ament <[email protected]> >>>>> wrote: >>>>> >>>>>> It's a good approach, I do something similar at times. However, you >>>>>> need to make sure the beans have scopes to avoid this memory leak. >>>>>> >>>>>> >>>>>> On Fri, Feb 27, 2015 at 1:47 PM Karl Kildén <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hrmm not sure what you mean. This is not a framework it is business >>>>>>> logic and I really like to put validators in a list like this instead >>>>>>> of if >>>>>>> else if else if else if >>>>>>> >>>>>>> On 27 February 2015 at 19:37, Romain Manni-Bucau < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Mark will surely say you that configuring anyThingCriterion will >>>>>>>> make your iterable size (if i can say it) = 1 even if you have 100 >>>>>>>> criterions ;) >>>>>>>> >>>>>>>> this is not a real spi >>>>>>>> >>>>>>>> >>>>>>>> Romain Manni-Bucau >>>>>>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog >>>>>>>> <http://rmannibucau.wordpress.com> | Github >>>>>>>> <https://github.com/rmannibucau> | LinkedIn >>>>>>>> <https://www.linkedin.com/in/rmannibucau> >>>>>>>> >>>>>>>> 2015-02-27 19:34 GMT+01:00 Karl Kildén <[email protected]>: >>>>>>>> >>>>>>>>> Hi John! >>>>>>>>> >>>>>>>>> Summary: we use it as iterable >>>>>>>>> >>>>>>>>> Long story for completeness: >>>>>>>>> >>>>>>>>> Basically we get a thing from our business partner (inputThing) >>>>>>>>> and map it to our representation of thing (ProcessedThing) >>>>>>>>> >>>>>>>>> Each ThingCriterion can veto the processedThing and then they used >>>>>>>>> inputThing to print a pretty error message. When the Thing is enhanced >>>>>>>>> (happens all the time) we implement new ThingCriterion and they get >>>>>>>>> picked >>>>>>>>> up automatically... >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> @Inject >>>>>>>>> private Instance<ThingCriterion> thingCriteria; >>>>>>>>> >>>>>>>>> >>>>>>>>> public List<ValidationProblem> validateList(final >>>>>>>>> ProcessedThing thing, final InputThing inputThing) { >>>>>>>>> List<ValidationProblem> results = new ArrayList<>(); >>>>>>>>> for (final ThingCriterion criterion : thingCriteria) { >>>>>>>>> results.addAll(criterion.validate(thing, inputThing)); >>>>>>>>> } >>>>>>>>> return results; >>>>>>>>> } >>>>>>>>> >>>>>>>>> >>>>>>>>> Romain, >>>>>>>>> >>>>>>>>> Thanks for your help. Great suggestion will it have better perf >>>>>>>>> then just putting @ApplicationScoped on my ThingCriterion beans? >>>>>>>>> Probably >>>>>>>>> not important just curious. >>>>>>>>> >>>>>>>>> cheers >>>>>>>>> >>>>>>>>> On 27 February 2015 at 19:25, Romain Manni-Bucau < >>>>>>>>> [email protected]> wrote: >>>>>>>>> >>>>>>>>>> When I used this pattern I always did (for perf reason but side >>>>>>>>>> effect is behavior is what you want): >>>>>>>>>> >>>>>>>>>> @PostConstruct >>>>>>>>>> private void resolve() { >>>>>>>>>> value = instance......get(); >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>> then in the code don't use instance at all but value. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Romain Manni-Bucau >>>>>>>>>> @rmannibucau <https://twitter.com/rmannibucau> | Blog >>>>>>>>>> <http://rmannibucau.wordpress.com> | Github >>>>>>>>>> <https://github.com/rmannibucau> | LinkedIn >>>>>>>>>> <https://www.linkedin.com/in/rmannibucau> >>>>>>>>>> >>>>>>>>>> 2015-02-27 19:15 GMT+01:00 John D. Ament <[email protected]> >>>>>>>>>> : >>>>>>>>>> >>>>>>>>>>> Are you calling get() on the Instance with each request (or >>>>>>>>>>> whatever0 that comes into this bean? >>>>>>>>>>> >>>>>>>>>>> On Fri, Feb 27, 2015 at 1:13 PM Karl Kildén < >>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>>> To explain myself further ALL I had on my heap was my >>>>>>>>>>>> Instance<MyInterface>... and gc released 0.5% memory :) >>>>>>>>>>>> >>>>>>>>>>>> I had 200 000 of them at least. They where supposed to be four >>>>>>>>>>>> singletons. My idea was inject into @ApplicationScoped and omit to >>>>>>>>>>>> give >>>>>>>>>>>> them scope because they will be @ApplicationScoped anyways... >>>>>>>>>>>> Seems every >>>>>>>>>>>> invocation of my @ApplicationScoped bean recreated all instances. >>>>>>>>>>>> >>>>>>>>>>>> What I had was unrecoverable mem leak. Now I could be doing >>>>>>>>>>>> something stupid or Instance<MyInterface> has a problem or >>>>>>>>>>>> something else... >>>>>>>>>>>> >>>>>>>>>>>> Cheers >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 27 February 2015 at 19:05, Romain Manni-Bucau < >>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> If dependent it will be kept in enclosing bean. >>>>>>>>>>>>> Le 27 févr. 2015 19:00, "Lars-Fredrik Smedberg" < >>>>>>>>>>>>> [email protected]> a écrit : >>>>>>>>>>>>> >>>>>>>>>>>>> So does this mean that there will be a memory leak in the case >>>>>>>>>>>>>> Karl described? >>>>>>>>>>>>>> >>>>>>>>>>>>>> I have used similar constructs before so im curios (@Inject >>>>>>>>>>>>>> @Provider <some dep scoped bean> in an @ApplicationScoped bean >>>>>>>>>>>>>> and called >>>>>>>>>>>>>> get () on the injected provider). >>>>>>>>>>>>>> >>>>>>>>>>>>>> I thought for a while that it might get garbage collected >>>>>>>>>>>>>> when the created bean is outof scope or maybe then there is no >>>>>>>>>>>>>> way for >>>>>>>>>>>>>> @PreDestroy to be called? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Regards >>>>>>>>>>>>>> LF >>>>>>>>>>>>>> >>>>>>>>>>>>>> I thought that the created dep scoped bean would be >>>>>>>>>>>>>> On Feb 27, 2015 6:07 PM, "Romain Manni-Bucau" < >>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yes. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Will be destoyed with the bean where it is injected IIRC so >>>>>>>>>>>>>>> the app here. >>>>>>>>>>>>>>> Le 27 févr. 2015 16:59, <[email protected]> a écrit : >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hello! I have a bean with @ApplicationScoped. When I inject >>>>>>>>>>>>>>>> Instance<MyInterface> instance and my actual beans >>>>>>>>>>>>>>>> implementing MyInstance >>>>>>>>>>>>>>>> are dependentscoped they get recreated over and over and are >>>>>>>>>>>>>>>> not gc'd. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Expected behavior? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Cheers >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>>
