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