我正在使用工作程序JVM执行各种操作的应用程序服务器上工作。Jar文件自发地无法找到内部根资源
使用-cp开关启动worker jvms,并指定包含供应商库和其他重要功能的JAR文件。
我有一个非常有趣的问题,其中jar文件CLASSES加载和正确执行代码,但任何时候他们试图访问资源内的jar文件(具体与getResourceAsStream()方法),然后它吹起声称它不能找到它。我已经验证了这些资源肯定存在于正在加载的JAR中,事实上,如果我操纵JAR以在外部定位资源,它就可以工作。问题是这些都是专有的库,并没有与源代码,所以我陷入了瘫痪,我必须通过反编译和方法入口断点来做所有事情。
也许最奇怪的部分是这些库已经改变了很多个月,并且一直在其他(包括生产)应用服务器上工作。
他们是JRE 1.6.0_17
所以我的问题是
- 为什么会用-cp条目的JVM能够从罐子里装载类而不是资源
- 做任何事情在这个领域从JRE 1.6.0_06变为1.6.0_17(这已经在最近发生了变化)
为了阐明,在JAR结构中,这些资源在jar的根上,即:
resource.prop
META-INF/Manifest
package/package/class.class
JAR本身在加载时显然位于类路径中。 但是,所有以下决心空的(是的,这是推动我坚果所以我没有真正尝试所有3):
Jarclass.getClassLoader().getResourceAsStream("./resource.prop");
Jarclass.getClassLoader().getResourceAsStream("/resource.prop");
Jarclass.getClassLoader().getResourceAsStream("resource.prop");
这类似于Can't access resource in a JAR on all computers但没有解决这个问题。
,想到的唯一的事情是:JAR的可使用依赖于一些奇怪的行为在JRE实现自定义的类装载器(写一个类加载器是不平凡的)。问题一般局限于一家供应商的图书馆吗?如果你使用Jarclass.getClassLoader()。toString(),它是否表明这不是由JRE创建的ClassLoader? – Durandal 2012-08-14 17:24:49
令人难以置信的富有洞察力的评论预测了我在我的原始文章中甚至没有提到的东西。你是绝对正确的,有一个供应商正在使用自定义类加载器,并且它正在重载JRE标准类加载器,特别是加载资源。我的所有图书馆都没有改变,但我没想过要检查其他包含更改的类加载器的库。我研究了它,发现这是问题 - 供应商在对自定义类加载器所做的更改中犯了错误。谢谢! – 2012-08-15 18:15:46