Hi folks, I spent a bit of time hunting through heapdumps and I found out why Guice wasn't being cleanly unloaded:
http://code.google.com/p/google-collections/issues/detail?id=92#c6 Unfortunately, I couldn't find a good way around some of these references and had to resort to reflection to clear some internal fields - so if anyone knows of better solutions, feel free to comment on that issue! (perhaps a public shutdown API for the google-collections Finalizer thread would actually be better?) Anyway, I've uploaded a new _unofficial_ snapshot in case anyone wants to test it themselves: http://peaberry.googlecode.com/svn/branches/spike/lib/build/google-guice-peaberry-20081128.jar I also tagged the version stamp with peaberry to make clear this isn't a regular snapshot, just in case... This jar will now allow Guice to be cleanly undeployed... as long as there are no other leaks inside your web application ;) I tested it on GlassFish v2 and it works - although GC can be slow to unload classes if you're not using much of your heap - but you can always force GC via jconsole, etc. PS. users of GlassFish v3 prelude may still see a leak because their web-container thread pool appears to have a bug where they don't clear the thread-context-classloader before returning threads to the pool which keeps the web-application around until that thread is re-used: https://glassfish.dev.java.net/issues/show_bug.cgi?id=6082 Have a good weekend! -- Cheers, Stuart --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "google-guice" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/google-guice?hl=en -~----------~----~----~----~------~----~------~--~---
