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