Do security providers cause ClassLoader leaks in Java?

问题

In my Java EE (Glassfish 3.1.1) application I register a security provider:

public static final class XoauthProvider extends Provider {
    public XoauthProvider() {
        super("Google Xoauth Provider", 1.0, "Provides the Xoauth experimental SASL Mechanism");
        put("SaslClientFactory.XOAUTH", "blah.server.utils.XoauthSaslClientFactory");
    }
}

...

XoauthProvider xoauthProvider = new XoauthProvider();
Security.addProvider(xoauthProvider);

I have been receiving following exceptions after redeploys:

java.lang.IllegalStateException: WEB9031: WebappClassLoader unable to load resource [blah.server.utils.XoauthSaslClientFactory], because it has not yet been started, or was already stopped

I debugged a little, and it seems that after a redeploy, the server still uses the old classloader when loading this class.

If case I am correct, and it is a ClassLoader leak, what would be an appropriate way to deregister the security provider when the applcation is redeployed/undeployed? Or should I just manually unregister/reregister the provider before calling the method which eventually throws the exception?

By the way, I am using JRebel.

回答1:

Yes, it does seem that custom java.security.Provider registered with java.security.Security.addProvider() does cause classloader leaks, unless deregistered with java.security.Security.removeProvider("providerName") at application shutdown.

I have created a project that aims to prevent classloader leaks, which includes a test case that proves this does leak.

You can either make sure to clean up yourself using a ServletContextListener, as detailed here, or simply use my cleanup component (see here).

来源：https://stackoverflow.com/questions/9420190/do-security-providers-cause-classloader-leaks-in-java

标签

java-ee

glassfish

classloader

memory-leaks

jrebel