Java WebStart 缓慢,从无效文件夹请求库 [英] Java WebStart slow, requesting libraries from invalid folder

查看:22
本文介绍了Java WebStart 缓慢,从无效文件夹请求库的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

问题和疑问:Java webstarted 应用程序在基文件夹而不是 ./lib 中查找其类.

Problem and question: Java webstarted app looking for its classes in base folder instead of ./lib.

正如在 Java Web Start 应用程序反复询问不存在的文件的类似问题中所建议的那样我已经转向关闭jar签名,排除安全问题,问题依旧.

As suggested in similar question at Java Web Start applications ask repeatedly for un-existing files I have turned off the jar signing, to rule out the security issue, and the problem persists.

下面是关于这个简单 java 程序的网络内容的简洁示例:

Below find the clean example on what is going over the network for this simple java program:

public static void main(String[] args) {
    // TODO code application logic here
    System.out.println("Hello World! Initializing the class from the jar residing in lib/ folder. Expecting heavy network traffic...");

    //This class resides in lib/SampleJavaLibrary.jar
    //Initializing it just to excercise the class loader problem
    CDummyClass sDummy = new CDummyClass();

    System.out.println("Done");

}

在网络上(通过wireshark),可以观察到对基本文件夹中jars的重复请求,在某些调用中,我计算了多达10次重试,Web服务器以404回复.最终,loadClass成功,但仅在10次之后或对不存在的 jar 的更多请求.将此乘以给定程序中访问的类数,最终初始化速度非常慢.在这个简单的例子中,这个简单的类只有"2 次重试.

On the network (by wireshark), one can observe repeated requests for jars in base folder, On some calls I counted up to 10 retries, replied by web server with 404. Ultimately, the loadClass is successful, but only after 10 or more requests for nonexisting jars. Multiply this with the number of classes being accessed in given program, and you end up with very slow initialization. In this simple case, there are "only" 2 retries for this simple class.

一切正常,罐子都装好了,一切都很好:

It all starts normal, the jars are loaded, all is good and nice:

6   0.020921    192.168.1.35    192.168.1.130   HTTP    GET /mnt/vbox/workspace/WebStartSample/distC/launch.jnlp HTTP/1.1
8   0.028092    192.168.1.130   192.168.1.35    HTTP    HTTP/1.1 200 OK  (application/x-java-jnlp-file)
10  0.514038    192.168.1.35    192.168.1.130   HTTP    GET /mnt/vbox/workspace/WebStartSample/distC/lib/SampleJavaLibrary.jar HTTP/1.1 
11  0.520688    192.168.1.130   192.168.1.35    HTTP    HTTP/1.1 200 OK  (application/java-archive)
12  0.618640    192.168.1.35    192.168.1.130   HTTP    GET /mnt/vbox/workspace/WebStartSample/distC/WebStartSample.jar HTTP/1.1 
14  0.652541    192.168.1.130   192.168.1.35    HTTP    HTTP/1.1 200 OK  (application/java-archive)

这是麻烦开始的地方,在库类调用中:

This is where the trouble begins, at library class call:

16  0.943801    192.168.1.35    192.168.1.130   HTTP    GET /mnt/vbox/workspace/WebStartSample/distC/SampleJavaLibrary.jar HTTP/1.1 
18  0.991748    192.168.1.130   192.168.1.35    HTTP    HTTP/1.1 404 Not Found  (text/html)
22  0.997281    192.168.1.35    192.168.1.130   HTTP    GET /mnt/vbox/workspace/WebStartSample/distC/SampleJavaLibrary.jar HTTP/1.1 
24  1.004799    192.168.1.130   192.168.1.35    HTTP    HTTP/1.1 404 Not Found  (text/html)

最终,在上述重试之后,该类被找到并初始化(!),很可能来自已经存在的 jar,它在应用程序启动时加载.

Ultimately, after above retrying, the class is being found and initialized (!), most likely from the already existing jar, which was loaded at application startup.

为什么 jnlp 类加载器要查看基本文件夹,以及为什么要进行如此多的重试,这超出了我的理解.我确实尝试在调试器下运行,但找不到类加载器的来源,也无法自己弄清楚.

Why is jnlp class loader looking into base folder, and why for so many retries, is beyond me. I did tried to run under debugger, but could not find the sources for class loaders and could not figure it myself.

FWIW 这是我的 jnlp 文件,是的,我确实尝试了更新标签的所有变体,懒惰的,急切的,没有变化

FWIW here is my jnlp file, and yes, I did tried all variations of update tag, lazy, eager, no changes

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<jnlp codebase="http://mydebian.mydomain/mnt/vbox/workspace/WebStartSample/distC"    href="launch.jnlp" spec="1.0+">
    <information>
        <title>WebStartSample</title>
        <vendor>user</vendor>
        <homepage href=""/>
        <description>WebStartSample</description>
        <description kind="short">WebStartSample</description>

    </information>
<update check="always"/>

    <resources>
<j2se version="1.5+"/>
<jar href="WebStartSample.jar" main="true"/>


    <jar href="lib/SampleJavaLibrary.jar"/>
</resources>
    <application-desc main-class="webstartsample.Main">

    </application-desc>
</jnlp>

我怀疑 JNLPClassLoader() 有问题,即 webstart 中使用的特定加载器.

I suspect there is something wrong with the JNLPClassLoader(), that is the particular loader used within the webstart.

问候,

罗伯特

推荐答案

感谢大家的建议.安德鲁暗示要索引罐子",这为我指明了正确的方向......

Thanks everyone for suggestions. It was Andrew hint to 'index the jars' which pointed me to the right direction...

也就是说,jars(生成我当前选择的 IDE,Netbeans) 被编入索引.但是,主 jar 中的 META-INF/INDEX.LIST 包含对其他 jar 的引用,就好像它们位于主 jar 旁边的当前文件夹中一样.

Namely, the jars (produced my current IDE of choice, Netbeans) were indexed. However, the META-INF/INDEX.LIST within the main jar contained the references to other jars as if they were in current folder, next to the main jar.

JarIndex-Version: 1.0

WebStartSample.jar
webstartsample

SampleJavaLibrary.jar
newpackage

这导致 jnlpClassLoader(),使用主索引,并在代码库 url 中查找 jar,而它们实际上位于 ./lib url 子文件夹下.

That resulted in jnlpClassLoader(), using the main index, and looking for jars in codebase url, while they actually resided under ./lib url subfolder.

这是正确索引(手动重新创建)的样子:

This is how the correct index (recreated manually) looks:

JarIndex-Version: 1.0

WebStartSample.jar
webstartsample

lib/SampleJavaLibrary.jar
newpackage

让问题变得更糟的是,这样的 webstarted 应用程序不会失败,他们只会首先在错误的地方寻找类/jar,然后最终找到它们,大概已经加载了原始问题中描述的 bu jnlp 加载器.

To make the problem worst, such webstarted application would not fail, they would just look for classes/jars in wrong places first, and then eventually find them, presumably already loaded bu jnlp loader as described in original question.

简而言之,这与 Netbeans 构建和打包过程有关.

Briefly, this IS related to Netbeans build and packaging procedure.

我的直接修复是禁用 jar 索引,这导致正确和最小的网络流量,并大大改进了应用程序初始化.

My immediate fix was disabling the jar indexing, and that resulted in correct and minimal network traffic, and greatly improved application initialization.

要在 Netbeans 中执行此操作,请转到 Tools->Options->Miscellaneous->Ant->Properties 并添加 jar.index=false

To do it in Netbeans, go to Tools->Options->Miscellaneous->Ant->Properties and add jar.index=false

正确的解决方法是让 Netbeans 正确索引 jar,但这是另一个问题.

Proper fix would be to make Netbeans index the jar correctly but that is the another question.

再次感谢大家的建议.

附上.

  • janela util 在我的 jnlp 中没有发现重大故障
  • 包元素包括未做任何更改
  • mydebian 是指我的服务器,客户端是 win7,具有所有最新和最好的 java 运行时和 jdks,包括 netbeans 6.9(也用 7.0 测试,产生相同的问题索引)

这篇关于Java WebStart 缓慢,从无效文件夹请求库的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆