https://issues.apache.org/jira/browse/OWB-1032
impl should be quite easy if you want to give it a try 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-03-01 17:58 GMT+01:00 Lars-Fredrik Smedberg <[email protected]>: > @Romain could u send the link to the jira (s)? Thanks > On Mar 1, 2015 5:34 PM, "Lars-Fredrik Smedberg" <[email protected]> > wrote: > >> @Romain Yes... we use Provider when we know there is one implementation >> and we like to lazy initialize a dep bean inside an application scoped bean >> method.... guess we could use Instance and destroy until it gets fixed in >> owb. . >> >> We have cases for instance where thr factory that injects instance is >> application scoped but in that case the bean implementations are scoped and >> not dependent. >> On Mar 1, 2015 5:13 PM, "Romain Manni-Bucau" <[email protected]> >> wrote: >> >>> 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 >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>
