Avoid server calls for loose resources that do not

问题:

I'm developing an applet application which is compiled on Java 1.5 (compatible with 1.5+). It contains some resource property files that are bundled together in the same jar, which lies parallel to the Java package.

Whenever I access that resource file through applet it makes a request to server from where the applet is been downloaded. After that it reads the files from the jar and works as it used to be but I don't want it to make server request for those files.

This is how my java code access the resource file.

ResourceBundle messages = ResourceBundle.getBundle("resources/properties/Messages", locale);

I tried access in both ways:

ResourceBundle messages = ResourceBundle.getBundle("resources.properties.Messages", locale);

Both it had the same behaviour.

Note: Those resources are not available as loose resources in my web app.

回答1:

I got these details from server logs.. I was analyzing my server log for 404 and 500 responses ..

The 404 (not found) & 500 (server error) messages can be expected because the plug-in is trying to check if the cached resources are up to date. To do that, it needs to check the time last updated on the server version of the resource.

The complicating factor is that the resource can be expected to be in a Jar mentioned in the archive attribute of the applet or it can be a 'loose file' on the same path as the codebase specified. So if a resource is in the following path of a Jar:

/resources/properties/Messages_en_US.properties 

The JVM will also check

${codebase}/resources/properties/Messages_en_US.properties 

as well as each Jar.

To fix them, see the codebase_lookup parameter. This use-case needs:

<param name='codebase_lookup' value='false' >

That tells the JVM that there are no resources stored as loose files on the class-path, and only Jars are to be searched. It should stop the 404/500 messages being reported as often (for newer JREs that understand that parameter).

回答2:

I don't know much about the inner details of the Java Plug-in's caching of applets, but if your applet is using a .jnlp descriptor, I would try adding download="eager" to the descriptor's <jar> element.

You can also try defining your ResourceBundles as classes rather than .properties files. For instance:

package resources.properties;

import java.util.ListResourceBundle;

public class Messages
extends ListResourceBundle  {
    protected Object[][] getContents() {
        return new Object[][] {
            {"entry1", "Some message text"},
            {"entry2", "A different message"},
            // etc.
        };
    }
}

Just like properties files, you can define them for as many locales as you wish:

package resources.properties;

import java.util.ListResourceBundle;

public class Messages_es
extends ListResourceBundle  {
    protected Object[][] getContents() {
        return new Object[][] {
            {"entry1", "Some message text in Spanish"},
            {"entry2", "A different message in Spanish"},
            // etc.
        };
    }
}

If you define ResourceBundle subclasses, it's a good idea to remove the corresponding .properties files.