Thanks Romain for the explanation... I guess this will solve alot of the use-cases / cases we talked about.
Do you know what version of OWB this is implemented in? On Feb 28, 2015 10:08 PM, "Romain Manni-Bucau" <[email protected]> wrote: > 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 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>> >>>>>
