自定义系统类加载器和MessageDigest的奇怪行为 [英] weird behaviour of custom system classloader and MessageDigest

问题描述

我有一个使用自定义系统类加载器的应用程序，由 Djava.system.class.loader = class 参数设置。该应用程序使用RMI。 eclipse中的一切工作正常，但如果我导出一个可运行的jar，则会发生以下错误：

I have an application which uses a custom system classloader, set by the Djava.system.class.loader=class parameter. The Application uses RMI. Everything works fine out of eclipse, but if i export a runnable jar, this error happens:

Caused by: java.lang.SecurityException: SHA MessageDigest not available
    at sun.rmi.server.Util.computeMethodHash(Unknown Source)
    at sun.rmi.server.UnicastServerRef$HashToMethod_Maps.computeValue(Unknown Source)
    at sun.rmi.server.UnicastServerRef$HashToMethod_Maps.computeValue(Unknown Source)
    at sun.rmi.server.WeakClassHashMap.get(Unknown Source)
    at sun.rmi.server.UnicastServerRef.exportObject(Unknown Source)
    at sun.rmi.registry.RegistryImpl.setup(Unknown Source)
    at sun.rmi.registry.RegistryImpl.<init>(Unknown Source)
    at java.rmi.registry.LocateRegistry.createRegistry(Unknown Source)

我自然试图解决这个问题，写了一个简单的 MessageDigest md = MessageDigest.getInstance（SHA）; 作为我主要的第一行。基本上也是如此。确切的错误是：

I naturally tried to pin this problem down, and wrote a simple MessageDigest md = MessageDigest.getInstance("SHA"); as the first line in my main. Basically the same happens. The exact error is:

java.security.NoSuchAlgorithmException: SHA MessageDigest not available
    at sun.security.jca.GetInstance.getInstance(Unknown Source)
    at java.security.Security.getImpl(Unknown Source)
    at java.security.MessageDigest.getInstance(Unknown Source)

然后我尝试使用一个简单的ClassLoader作为SystemClassloader。它现在看起来像这样：

Then i tried to use a simple ClassLoader as the SystemClassloader. it now looks like this:

public class RootClassLoader extends ClassLoader{
    @Override
    public Class<?> loadClass(String name) throws ClassNotFoundException {
        return super.loadClass(name);
    }

    public RootClassLoader(ClassLoader loader){
        super(loader);
    }
}

仍然会发生同样的情况。如果我将这个场景重建为一个新项目，一切都按预期工作，所以很明显其他东西都被破坏了，但是现在我不知道是什么。

and still the same happens. If i rebuild this scenario as a new project, everything works as expected, so obviously something else is broken, but by now i have no idea what.

我不使用安全经理在程序的任何地方，我使用oracle的标准jre7。

I dont use a security manager anywhere in the program, and i use the standard jre7 by oracle.

我可能忽略了什么？

更新：
即使我不重写 loadClass 方法所有，错误发生...它似乎失败只是因为有一个非标准的系统类加载器，无论实际做什么

Update: Even if i dont override the loadClass method at all, the error occurs... It seems to fail simply because there is a non-standard system classloader, regardless of what that actually does

更新2：
我列出了所有可用的Securityproviders /算法。当我在eclipse中执行代码时（仍然使用自定义类加载器），一切看起来都是有序的，但在执行runnable jar时，完整的 SUN版本1.7 提供程序似乎丢失了。没有自定义类加载器，一切都是一样的。在只包含上面的szenario（并且有效）的环境中，一切看起来都一样，每个星座都有 SUN版本1.7 提供商。

Update 2: I listed all the available Securityproviders/algorithms. When i execute the Code in eclipse (still with the custom classloader), everything seems in order, but while executing the runnable jar, the complete SUN version 1.7 Provider seems to be missing. Without the custom classloader, everything is the same. In a environment which contains just the szenario above (and which works) everything looks the same, and every constellation has the SUN version 1.7 Provider.

更新3：
-verbose：class 显示包 sun .security.provider 以及更多内容未加载。我不知道为什么，因为两个替代方案都是从 jsse.jar 加载缺少的包来自哪里，并打印 [打开C：\\ \\ Program Files \Java \jre7 \lib \ jsse.jar] （更新4：实际上它 加载了。很久以后。甚至 sun.security.provider.SHA 在两个变种中加载。这更奇怪了）

Update 3: the -verbose:class showed that the package sun.security.provider and more does not get loaded. I dont know why though, because both alternatives are loading classes from jsse.jar where the missing package comes from, and both print [Opened C:\Program Files\Java\jre7\lib\jsse.jar] (Update 4: actually it does get loaded. just much later. Even sun.security.provider.SHA gets loaded in both variants. This is even more weird)

推荐答案

我找到了这个问题的根源。我不知道为什么以及如何实际发生，但似乎我使用的第三方lib是罪魁祸首。当我删除lib时，一切正常。再一次，我不知道这是怎么可能的

I found the root of this problem. I dont know why and how this actually happened, but it seems that a 3rd party lib i was using was the culprit. When i removed the lib, everything worked fine. Again, i have no idea how this is even possible

这篇关于自定义系统类加载器和MessageDigest的奇怪行为的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！