安全提供程序会导致 Java 中的类加载器泄漏吗?

发布于 2025-01-08 13:19:27 字数 874 浏览 0 评论 0原文

在我的 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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

长亭外,古道边 2025-01-15 13:19:27

是的,使用 java.security.Security.addProvider() 注册的自定义 java.security.Provider 似乎确实会导致类加载器泄漏,除非使用 java 取消注册。 security.Security.removeProvider("providerName") 在应用程序关闭时。

我创建了一个项目,旨在防止类加载器泄漏,其中包括一个测试用例证明这确实泄漏了。

您可以确保使用 ServletContextListener 进行清理,详细信息此处,或者直接使用我的清理组件(请参阅此处) 。

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).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文