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