There is no well defined time.
A class loader is garbage collected just like any other object. I.e. when there
are no direct strong references to it. Objects refer to their reflective Class
objects. And each Class object refers to the ClassLoader that *defined* it from
raw bytes.
When you uninstall a bundle all you do is to get the OSGi container to stop
referring to that bundle's class loader directly. The container drops references
to registered service objects and listeners. It calls BundleActivator.stop() to
tell the bundle to kill any threads that might keep strong references to bundle
content from their stacks. It dispatches unregistration events for the dead
bundle's services so the bundles using them cooperate by dropping their
references as well. Finally it dispatches a bundle event as well for any "exotic
users" like extenders.
Shutdown under OSGi and generally Java is a gradual fading away until garbage
collected rather than a deterministic process. Check your code to see if the
process is interrupted by uncooperative bundles that don't listen for service
events for example.
I am not sure how exactly native code can refer to Java objects and if that
counts for a strong reference. Sorry if all said above does not help :P
Cheers,
Todor
Holger Hoffstätte wrote:
Can someone shed a ray of light on when exactly a bundle's classloader is
(supposedly) made eligible for GC? I'm working with native code and while
it is not required to re- or unload my bundle, it would be nice to have a
better grasp of potential lifecycle issues.
Right now felix (on Windows) fails to delete a .dll (since it's still
mapped) and complains when the bundle is uninstalled; equinox seems to
ignore the error and marks the bundle resources for deletion on the next
startup.
Thanks!
Holger
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
