java jre 7u45破坏了classloader.getResources（）？

我有代码迭代classLoader.getResources（“META-INF/MANIFEST.MF”）的结果，以返回类路径上的JAR列表。从1.6.0_18一直到1.7.0_40，效果都很好。现在1.7.045通过显示关于混合签名/未签名代码的安全警告弹出窗口打破了这一点

演示问题的小型自包含测试用例：

package testcase;
import java.io.*;
import java.net.*;
import java.util.Enumeration;
import java.util.logging.*;
public class TestCase {
    public static void main(String[] args) {
        getAllJarUrls();
    }

    public static void getAllJarUrls() {
        try {
            final Enumeration<URL> mfUrls = Thread.currentThread().getContextClassLoader().getResources("META-INF/MANIFEST.MF");
            while (mfUrls.hasMoreElements()) {
                URL jarUrl = mfUrls.nextElement();
                if (!jarUrl.getProtocol().equals("jar")) {
                    continue;
                }
                try {
                    System.out.println(jarUrl.toURI());
                } catch (URISyntaxException ex) {
                    Logger.getLogger("testcase").log(Level.SEVERE, null, ex);
                }
            }
        } catch (IOException e) {
            Logger.getLogger("testcase").log(Level.SEVERE, null, e);
        }
    }
}

testcase.jar已签名。它甚至包含了所有新的清单属性： 应用程序名称：testcase 权限：所有权限 代码库：*

deploy.jar中反编译的CPCallBackHandler从7u40到7u45的差异显示了显著的变化。LiveConnect的更改似乎破坏了现有功能。不，这里没有LiveConnect

还有其他人碰到过这个吗？解决方案的建议？提交一个bug

（注意：也发布在OTN java论坛上，但我希望这里有一个更快的答案：）

谢谢，

---

Chris将此添加到jar的清单中：

Trusted-Library: true

---

已记录。

关于受信任位置的警告-来自链接文档-

受信任的库属性用于应用程序和小程序 设计为允许不受信任的组件。没有显示任何警告对话框 如图所示，应用程序或小程序可以加载包含 不受信任的类或资源

因此，如果您希望允许不受信任的资源，请使用此选项（这是我阅读本文的方式）

问题的根源在于清单迭代包含了与WebStart本身（javaws.jar、deploy.jar）关联的未签名资源

我用电脑解决了我的问题-

---

JARDesc[]jars=JNLPClassLoader.getLaunchDesc（）.getResources（）.getquengeoralljardescs（true）

我们开始遇到7u45的

classloader.getResourceAsStream（）

问题。我们对JAR进行了签名，但没有嵌入

JNLP-INF/{APPLICATION.JNLP，APPLICATION_TEMPLATE.JNLP}

（因为我们需要两个未签名的APPLICATION.JNLP变体，具有不同的堆设置）

---

无论如何，我们通过嵌入

JNLP-INF/APPLICATION\u TEMPLATE.JNLP

解决了这个问题。如果其他人有这个特殊的问题，就发布吧。

基于Netbeans RCP的应用程序有这个问题。Netbeans加载每个清单文件以读取其自己的入口。这会导致应用程序中包含的每个JAR都出现安全异常。在我们看来，Java认为清单文件本身是不受信任的资源。不知道这是故意的还是错误。

令人惊讶的是，OTN成功了！！只需将“Trusted Library:true”添加到清单中，所有操作都与以前一样。我已经为此提交了java bug#9007507。您可以提供该bug的链接吗？应该是，但oracle尚未将其公开。我不知道你是怎么把臭虫公之于众的。这是我提交的关于这个烂摊子（7u45）的2篇文章中的第一篇。另一个是9007571，这是7u45 webstart类装入器中引入的死锁。我现在又回到40岁。我们有一个旧的基于OSGi的应用程序，它因此而崩溃。我猜OSGi+WebStart应用并不多，或者他们可能已经注意到了：）Adrian，不幸的是，我必须得到的不仅仅是JAR列表。这在代码中是一个更隐蔽的webstart bug的解决方法，该bug与webstart类加载器中JAR的缓存有关。请参阅java bug 6967414。他们声称在各种版本中都已修复，但从未真正修复过。解决方法是通过一系列反射将软引用转换为硬引用。在我看来，这是我15年来遇到的最麻烦的java bug之一。到目前为止，我们也遇到了这个问题。我们所有的JAR都是有符号的，我们没有使用任何无符号代码。Chris的解决方案似乎有效，唯一需要注意的是Trusted Libary:true属性更改了用于加载jar的类加载器。这可能会影响任何不受信任的JAR（更改类路径层次结构），但是如果您对所有JAR都这样做，应该没问题。虽然客户类加载器可能有问题，但我尝试嵌入JNLP-INF/APPLICATION.JNLP，但实际上对我的情况没有帮助。但是谢谢你的提示。我们将开始嵌入application_template.jnlp，以覆盖所有基础，因为在将来的更新中可能需要它（如7u51中的权限清单属性）。

CacheEntry[http://localhost/test/testcase.jar]: updateAvailable=true,lastModified=Tue Oct 15 21:09:21 CDT 2013,length=6314
jar:file:/C:/jre32/1.7.0_45/lib/javaws.jar!/META-INF/MANIFEST.MF
jar:file:/C:/jre32/1.7.0_45/lib/deploy.jar!/META-INF/MANIFEST.MF
jar:file:/C:/jre32/1.7.0_45/lib/plugin.jar!/META-INF/MANIFEST.MF
jar:file:/C:/jre32/1.7.0_45/lib/deploy.jar!/META-INF/MANIFEST.MF
Trace level set to 5: all ... completed.Trace level set to 5: all ... completed.
security: resource name "META-INF/MANIFEST.MF" in http://localhost/test/testcase.jar : java.lang.SecurityException: trusted loader attempted to load sandboxed resource from http://localhost/test/testcase.jar

Trusted-Library: true