Hi! As Romain already explained there was only the chance to not cleanup dependent beans properly (which might create a mem leak), or to collect them to be able to release them laster. Which in case of @ApplicationScoped parent means another mem leak. The very same problem appears if you e.g. inject a @Dependent bean into a producer method or @Inject method. This case is only fixed in the CDI-1.1 spec by marking the injection point as @TransientReference. I would need to dig the spec if we only let this apply to Instance<T>. And we do not really care about Provider<T> at all in CDI, except that Instance<T> extends Provider<T>.
An easy solution would be to simply use DeltaSpike BeanProvider#getDependent. That way you can also properly destroy the bean _inside_ your loop already. LieGrue, strub > Am 01.03.2015 um 18:02 schrieb Romain Manni-Bucau <[email protected]>: > > 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 | Blog | Github | LinkedIn | Tomitriber > > 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 | Blog | Github | LinkedIn | Tomitriber > > 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 | Blog | Github | LinkedIn > > 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 | Blog | Github | LinkedIn > > 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 > > > > > > > >
