I wrote up a blog that discusses what I found in the agent regarding its
classloading and why we were getting errors during hot-deployment:
http://management-platform.blogspot.com/2009/01/classloaders-keeping-jar-...
Thanks to Jay - he pointed me to the place in the code where it was
failing. From there, it was just a matter of stepping through some JRE
code and googling and, well, the blog explains the problem.
In the end, we don't really need to do that hack that I show in the blog
(as I mention in the last paragraph). It turns out, in two places in
the code we were creating temporary classloaders just so we could get a
stream of the plugin descriptor from the jar file - and that was opening
the plugin jar files (and on Windows, locking them too). I replaced the
temporary classloaders with code that simply gets the stream using the
JarFile API. This fixed the problem.
This should put to bed those nasty "the JMX plugin is not in the
dependency graph" errors we sometimes got in the agent (at least, I hope
it does).
That said, we still have one problem which manifests itself in the agent
being unable to delete the virt plugin's data/tmp directory at shutdown.
See the comment in RHQ-1399 for the stack that shows the libvirt code
asking the classloader to load the jna jar file - I do not know why this
is still locked. Here's the link to that RHQ issue:
http://jira.rhq-project.org/browse/RHQ-1399?focusedCommentId=13893#action...