I could see is UnifiedLoaderRepository3 indeed sends a notificaton of the classLoader... and if you buffer such notification that would generate a leak.
I don't know how to avoid the buffer on the sun's implementation.
One thing that I thought though, was to make the attribute source on javax.management.Notification a WeakReference, but sounds a weird solution. (Brain storm).
Another possibility would be to not send ClassLoading notifications when using Sun's JMX? (Another brain storm)
This is a job for JMX/ClassLoader experts.
I can confirm that in our case at least the remote JMX connections are coming from a jconsole instance that is used to watch the perm gen size and initiate various MBean actions.
There are no expected listeners, its just part of the jmx management
interface to emit notifications when class loaders are added/removed
from a repo. I do see that there is a
org.jboss.aop.deployment.LoaderRepositoryUrlUtil class referencing the
CLASSLOADER_ADDED/CLASSLOADER_REMOVED event types to track some internal
sequence number, but that is the only explicit usage in the 4.2 codebase
I can find. In the past there were thoughts about using these notifications to handle implicit deployment dependencies based on usage of a class from the repository, but this was never fleshed out.
I don't see a problem with wrapping the class loader in a WeakReference
to avoid the jmx layer being a strong referent. NotificationListeners
would have to be aware that the Notification user data has changed to a
WeakReference. This could be added as an optional behavior based on a
system property. Notification emission could also be disabled altogether as well based on this property.