I see. So there's a different proxy returned at each call to lookup(), and that proxy has its own ThreadLocal to track actual components. IIRC, Hivemind provides this. Don't know about Spring, but it certainly could be done with a custom BeanFactory.
Yepp
So this simplifies component development. And as I indicated, it also opens the road for constructor/setter based injection as injected components need to be thread safe.
I remember of some people having some OutOfMemoryError exceptions when using some RequestLifeCycle components in complicated pipelines involving many subrequests, because the RLC components weren't released even if they actually were no more useful. Automatic pool management may lead to the same kind of problems, don't you think?
Hmm, perhaps - perhaps we can optimize this feature "somehow"
Or what we need is that the proxy tracks some methods that indicate end of use of the proxied component that can then go back to the pool before the end of the request (e.g. connection.close() or contenthandler.endDocument())The proxies only fix a defect Avalon had for years, nothing more. We can "fine-tune"
But all this will complexify a lot the small CoreManager and I'm wondering if this is a good idea to write yet another dependency injection container when some widely used ones already exist. Ask Ugo, which one he prefers ;-)
the system by specifying where to *not* use the proxies: for example all sitemap
components.
In the end, I think proxies for pooled components make the development easier as you don't have to care about this anymore.
Carsten
-- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
