Yes and no. In owb it does ATM - opened a jira linked to it - but actually provider can be a single instance with lazy eval where Instance is by design multiple instances. Le 1 mars 2015 16:32, "Lars-Fredrik Smedberg" <[email protected]> a écrit :
> Shouldn't Provider faces the same issue as Instance? > On Mar 1, 2015 10:44 AM, "Romain Manni-Bucau" <[email protected]> > wrote: > >> Owb 1.5 >> >> I dont think it is in provider api >> Le 1 mars 2015 03:13, "Lars-Fredrik Smedberg" <[email protected]> a >> écrit : >> >>> @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 >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>
