Applet served by Java Web Start, resources requested to WEB Server before look in the JAR files

Question

I am new here and I apologize for my bad English.

I have a little problem with an Applet class served by Java Web Start technology. I have some platform dependent JAR files which Web Start download correctly, but when I get the content by getResourceAsStream(String fileName) method of ClassLoader object, first is made a GET request of fileName to WEB Server, after received a 404 Not Found response, the resource is loaded correctly from JAR file. The problem is that I have many files inside the JAR, so I have a lot of unnecessary load on the WEB Server and consequently I have to wait for long time before I can use the Applet.

Searching on Google I have found some discussions where it was said to add the parameter codebase_lookup with value false, but this has not solved the problem. This page, in relation to the codebase_lookup parameter, says that the default behavior of an Applet is to load resources from JAR file and then from the Applet codebase, in my case the behavior is the opposite.

I also added the eager="true" attribute for each JAR resource in the .jnlp file, but the behavior is always the same. The Applet was developed and built with NetBeans, the html and jnlp files generated are the following.

launch.html

<applet width="300" height="300">
        <param name="jnlp_href" value="launch.jnlp"/>
        <param name="codebase_lookup" value="false"/>
</applet>

launch.jnlp

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<jnlp codebase="http://192.168.23.4/contact" href="launch.jnlp" spec="1.0+">
<information>
    <title>ContactNR</title>
    <vendor>Roberto Santini</vendor>
    <homepage href=""/>
    <description>ContactNR</description>
    <description kind="short">ContactNR</description>
</information>
<resources>
<j2se version="1.5+"/>
<jar eager="true" href="ContactNR.jar" main="true"/>
<jar eager="true" href="lib/VDK.jar"/>
<security>
    <all-permissions/>
</security>
</resources>
<resources arch="amd64" os="Linux">
    <jar eager="true" href="lib/liblinux64.jar"/>
</resources>
<resources arch="x86_64" os="Linux">
    <jar eager="true" href="lib/liblinux64.jar"/>
</resources>
<resources arch="x86" os="Linux">
    <jar eager="true" href="lib/liblinux.jar"/>
</resources>
<resources arch="i386" os="Linux">
    <jar eager="true" href="lib/liblinux.jar"/>
</resources>
<resources os="Windows">
    <jar eager="true" href="lib/libwin.jar"/>
</resources>
<resources os="MacOs">
    <jar eager="true" href="lib/libmac.jar"/>
</resources>
<applet-desc height="300" main-class="com.netresults.voip.ContactNR" name="ContactNR" width="300">
    <param name="codebase_lookup" value="false"/>
</applet-desc>
</jnlp>

Can someone help me? Thanks at all,

Roberto.

Rounds

which Java version, which browser? codebase_lookup=false is working for me on IE7 / Java plugin 2 – Urata

If you open the Java console and set the log level to maximum (press '5' in the console window), you'll see the URL that is triggering the 404. This should help figure out what invalid request is being made. In my experience this is often caused by logging frameworks like log4j and commons logging scanning the classpath for config files. – Immaculate

The JNLP file shown above is malformed XML. Try validating non-working apps. in JaNeLA (pscode.org/janela) to avoid the GI/GO factor. – Platelayer

Might this be related to question: #5771307 – Schnur

Answer 1

I solved this problem by adding an index to the JAR-file. After building your jar, run the command:

JAR -i <path/to/jar-file>

It has to be run as a separate step from the actual JAR-ing.

Explanation: When the startup-process encounters an INDEX.LIST in META-INF, it trusts this, and will not go looking for the files on the server.

Dimitri

Thanks, This has solved my problem too. But as I am using ant to build, I inserted the index param to jar task: ant.apache.org/manual/Tasks/jar.html – Exserviceman

Answer 2

I recently had a similar problem with log4j querying for missing resources via GETs. Maybe web-based classpath still has some priority over bundled jars in your case? Well, you may try to pack all the jars into one. This of course complicates the build, but you may try this just once manually to see whether problem vanishes.

Sommelier