@Romain btw destroy should work on Provider also right? On Mar 1, 2015 2:56 AM, "Lars-Fredrik Smedberg" <[email protected]> wrote:
> 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 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>
