2008/11/27 Gili Tzabari <[EMAIL PROTECTED]> > > Stuart McCulloch wrote: > > can you be a bit more clearer about the link from the Finalizer thread > > to the Tomcat classes? are you loading Guice as a separate bundle > > or elsewhere in the hierarchy, like inside a Tomcat classloader? > > Not as far as I know. I am just using Guice as a library inside my > webapp. I'm not sure whether "bundle" means something different than a > library in this context. >
bundle is an OSGi term - since you're using GFv2 you're probably using a Tomcat classloader > > here's how things worked for me - I loaded Guice in Felix as an OSGi > > bundle, so the Finalizer thread (which gets its own classloader) was > > in a classloader chained off the Guice bundle classloader > > What is the "Guice bundle classloader"? > in OSGi each bundle gets its own classloader - but for you this would be the webapp classloader @Inject @Pitch with OSGi instead of having large monolithic webapps, you can break them into several bundles and then re-use bundles between applications (bundles are versioned, so you can have several versions of say Xerces safely loaded at the same time) - OSGi manages the wiring for you that's the idea at least - of course you may hit a few speed-bumps when moving legacy code to the OSGi model, but there are several Enterprise platforms coming out to help with this, like GF. here's an ongoing case study about moving to OSGi: http://raibledesigns.com/rd/entry/building_linkedin_s_next_generation http://www.slideshare.net/linkedin/building-linkedins-next-generation-architecture-with-osgi-presentation http://blog.linkedin.com/?s=osgi they decided to use Spring-DM (which is Spring's OSGi support) but don't hold that against them ;) > the Finalizer thread hangs around until it detects that the classloader > > with the reference queue (in this case the Guice bundle) is eligible for > > GC, so until this happens you will see it appear as a GC root > > > > what might be happening in your case is that something else is keeping > > the Guice classloader alive, in which case the Finalizer thread will stay > > alive (but it won't cause a memory leak, because it shuts down when it > > spots certain key classes being enqueued - as mentioned earlier) > > I suspect warp-servlet is the culprit. > yes, I'd suggest tracing warp-servlet first to make sure the injector is cleared btw, the unofficial patches that I applied to Guice can be found in my earlier note ( if it's really necessary I could make the patched source available somewhere ) > > once the Guice classloader is eligible for GC, the Finalizer thread will > > detect it and shutdown, allowing both classloaders to be unloaded... > > > > [ ps. you might also want to look at GlassFish v3 prelude ] > > I'm downloading it now. Is this a reasonable version? > https://glassfish.dev.java.net/downloads/v3-prelude.html or are you > using nightly builds from somewhere else? > for my test I used a plain OSGi container as I wasn't using JEE - but the v3 prelude should be ok Gili > -- 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 -~----------~----~----~----~------~----~------~--~---
