[mkouba]

So I did a quick test. The optimization is only applied to @Dependent managed beans, producer methods and producer fields with no @PreDestroy/disposer method which have no transitive dependency. In your case, HttpRequestContext is a built-in bean and so the optimization is not applied. As a result, the producer method TraceProducer.getTrace() has a dependency and its CreationalContext is retained and so is the child CreationalContext for the built-in HttpRequestContext. So both instances "leak" (in fact, this is correct per the spec). In theory, we could apply the optimization to built-in dependent beans as well. I've created a new issue to track this - [WELD-1996] Creational context - do not store dependent instances of built-in beans - JBoss Issue Tracker.

[chrisjr]

Interesting; so @Trace String actually was leaking when it had a dependency on HttpRequestContext? (I didn't notice when I iterated though the instances in the heap dump, but maybe I just didn't recognise it?) I think I also noticed this problem when injecting BeanManager instead of HttpRequestContext into @Produces methods.

Is this optimisation applied generally to dependent beans, or only when invoking Instance.get()?

[mkouba]

I think I also noticed this problem when injecting BeanManager instead of HttpRequestContext into @Produces methods.

Yep, BeanManager is also a built-in bean.

Is this optimisation applied generally to dependent beans, or only when invoking Instance.get()?

It's applied generally.

[chrisjr]

It's applied generally.

Hmm, then it sounds like none of my @Produces String (etc) configuration methods should ever create a contextual instance anyway... unless InjectionPoint is also considered to be a built-in bean?

[mkouba]

I'm not sure I understand. But if you're talking about injection point metadata, i.e. injecting javax.enterprise.inject.spi.InjectionPoint in your producer method, then yes - this is also a built-in bean (see also 5.5.7. Injection point metadata, "The container must provide a bean with scope @Dependent, bean type InjectionPoint...").

[chrisjr]

I'm not sure I understand.

I have written a library for injecting metadata into my applications, and its central method is essentially:

@ConfigParam("*") // non-binding
@Produces
String getString(InjectionPoint injection) {
    return ...;
}

I had always assumed that because String has no @PreDestroy method and because I provide no @Disposes method that this would effectively be "POJO injection". However, if InjectionPoint is a built-in bean which WELD considers to be a dependency of my @ConfigParam String then it appears that I have been mistaken... .