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 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >>> >
