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