安全提供程序会导致 Java 中的类加载器泄漏吗?
在我的 Java EE (Glassfish 3.1.1) 应用程序中,我注册了一个安全提供程序:
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);
重新部署后我一直收到以下异常:
java.lang.IllegalStateException: WEB9031: WebappClassLoader unable to load resource [blah.server.utils.XoauthSaslClientFactory], because it has not yet been started, or was already stopped
我调试了一下,似乎在重新部署后,服务器在加载此类时仍然使用旧的类加载器。
如果我的情况是正确的,并且这是类加载器泄漏,那么在重新部署/取消部署应用程序时取消注册安全提供程序的适当方法是什么?或者我应该在调用最终抛出异常的方法之前手动取消注册/重新注册提供者?
顺便说一句,我正在使用 JRebel。
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.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
是的,使用
java.security.Security.addProvider()
注册的自定义java.security.Provider
似乎确实会导致类加载器泄漏,除非使用java 取消注册。 security.Security.removeProvider("providerName")
在应用程序关闭时。我创建了一个项目,旨在防止类加载器泄漏,其中包括一个测试用例证明这确实泄漏了。
您可以确保使用
ServletContextListener
进行清理,详细信息此处,或者直接使用我的清理组件(请参阅此处) 。Yes, it does seem that custom
java.security.Provider
registered withjava.security.Security.addProvider()
does cause classloader leaks, unless deregistered withjava.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).