Java安全提供程序是否会导致ClassLoader泄漏？

问题描述

在我的Java EE（Glassfish 3.1.1）应用程序中，我注册了一个安全提供程序：

  public static final class XoauthProvider extends提供商{
 public XoauthProvider（）{
 super（Google Xoauth Provider，1.0，提供Xoauth实验性SASL机制）; 
 put（SaslClientFactory.XOAUTH，blah.server.utils.XoauthSaslClientFactory）; 
 
 
 
 
 
 XoauthProvider xoauthProvider = new XoauthProvider（）; 
 Security.addProvider（xoauthProvider）; 
  

我在redeploys之后收到以下例外情况：

  java.lang.IllegalStateException：WEB9031：WebappClassLoader无法加载资源[blah.server.utils.XoauthSaslClientFactory]，因为它尚未启动或已停止
  

我调试了一下，似乎重新部署后，服务器在加载此类时仍然使用旧的类加载器。

如果我的情况正确，并且是ClassLoader泄漏，那么在重新部署/取消部署应用程序时，注销安全提供程序的适当方式是什么？或者我应该在调用最终引发异常的方法之前手动取消注册/重注册提供程序？

顺便说一句，我使用JRebel。

解决方案

是的，似乎自定义 java.security.Provider 注册了<$ c $除非使用 java.security.Security.removeProvider（providerName）会导致类加载器泄漏。 >在应用程序关闭。

我创建了，旨在防止类加载器泄漏，其中包括一个证明它泄漏的测试用例。

您可以确保使用a ServletContextListener ，详见或si mply使用我的清理组件（参见）。

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.

解决方案

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

这篇关于Java安全提供程序是否会导致ClassLoader泄漏？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！