i am currently investigating a memory leak in an application i have written. After doing some analysis on heap dumps i obtained I zeroed in on an odd behavior of MyFaces CODI.
I make heavy use of the ViewAccessScope and recently modified my code to log @PostConstruct and @PreDestroy callbacks together with the hashcode for the corresponding instance.
The PostConstruct callback is executed as I would expect, e.g. when coming from a totally different view which didn't use the bean. What bugs me is that the @PreDestroy callback is never invoked (even though i (think i) made sure there are no references to the bean anywhere on the following views).
What makes this even more confusing for me is the fact that I wrote a simple little test program with 3 views, each backed by a ViewAccesScoped Bean. When changeing the view the beans get destroyed just as I'd expect because the bean i am coming from is not referenced anywhere in the bean for the view i am navigating to.
So i guess my question would be, are there any other factors besides bean references to consider regarding the cleanup / destroy behaviour of ViewAccessScoped beans ?
I am using MyFaces CODI in Version 1.0.5 on JBoss AS Final 7.1.1
I am going to answer my own question here-
The reason why the beans in question never are destroyed is because they indeed share an object which never gets unscoped. It is an object which is provided by a custom CDI portable extension.
So CODI is actually working as intended, the memory leak is not caused by CODI but by the custom CDI extension.
As I see it, the problem is that the object provided by the extension is not proxied but the instance created by the CDI extension is shared across all consuming beans.