JDK-4668479 : Option to turn off codebase lookup in AppletClassLoader during resource requests
  • Type: Enhancement
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version:
    1.2.0,1.3.0,1.3.1_03,1.3.1_07,1.4.0,1.4.1,6 1.2.0,1.3.0,1.3.1_03,1.3.1_07,1.4.0,1.4.1,6
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS:
    generic,linux,solaris_8,windows_2000 generic,linux,solaris_8,windows_2000
  • CPU: generic,x86,sparc
  • Submitted: 2002-04-15
  • Updated: 2017-05-16
  • Resolved: 2005-08-03
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6
6 b46Fixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Description
Customer Problem Description:
------------------------------

We have an applet deployed on a weblogic 6.1 server.  Our client is using the 1.3.1 plug in.  Our applet has many jar files.
For the most part everything works.  Since we have many different property files and support for 9 languages, we use the java.util.ResourceBundle class to manage loading these files.
The property files are located IN the jar files.  We only specify the language, so the names look like ... Emulator_de.properties, Emulator_en.properties, etc.

The resource bundle has a private method called calculateBundleNames.  This method defines the list of names the class will look for while trying to load the file.
This makes sense, since it is supposed to go from specific to general.
Problem:
Each time the resourcebundle tries to load a file that is not found in the jars ( Emulator_de_US.properties) it tries to go back to the server and look for the property file.
Now each time it wants to go past our proxy server and through the firewall, java asks for our name and password.
Our product works fine as long as we type in our name and password around 50 times. 

We would like some way of getting around this.
Is there a way for the programmer to specify to resource bundle not to look back on the server?
This may be a class loader issue.  We would also like to reduce traffic.  If I have 20,000 people logging in each day, that are each making 50 unnecessary hits looking for classes ....
we are talking about 20,000 x 50 = 1,000,000 unnecessary requests to the server.

I talked to the internationalization at the Java One BOF.  They agreed that the resourceBundle should not always hit the server.

I have tried to create my own resource bundle with a naming scheme that meets our specific needs ...but I have had trouble since the class have a native method. ( getClassContext )

So to sum it up.
I need a way to keep resource bundle from hitting the server in order to support internationalization and reduce network traffic.

The real problem is the fact that resource bundle makes so many hits to the server when using an applet.The real solution is to avoid hitting the server
with the resource bundle. If we can do this, the other problem is never seen, (multiple authentication pop-ups from java plugin) and it reduces our unnecessary hits to the server.

I have looked at using 1.4 JRE but it seems to have the same problem.
TESTCASEBEGIN
Create an applet with many properties files.
Make sure there is a proxy server / firewall in between the client and the server.
Try to use resource bundle to read the properties files from the jars.

This should prompt you for you name and password for each time it looks back at the server.

here is the dialog

 Firewall: www.xyz.com/IP-ADDRESS
 Realm: sabre
 Scheme: basic
 User Name:
 Password:

  -YES-  -NO-  (buttons
[Image]

I do get an exception if I always click no.

CAUGHT EXCEPTION/ERROR : Can't find bundle for base name
/com/sabre/evoya/client/common/props/CommonMenuBar.properties, locale en

java.util.MissingResourceException: Can't find bundle for base name
/com/sabre/evoya/client/common/props/CommonMenuBar.properties, locale en

 at java.util.ResourceBundle.throwMissingResourceException(Unknown
Source)
 at java.util.ResourceBundle.getBundleImpl(Unknown Source)
 at java.util.ResourceBundle.getBundle(Unknown Source)



TESTCASEEND

Comments
SUGGESTED FIX implementation in Java SE 6 uses the following syntax: HTML parameter for applet to enable/disable lookup of resources from the codebase: <APPLET ...> <PARAM NAME="codebase_lookup" VALUE="true|false"> </APPLET> The default value for "codebase_lookup" is "true". The parameter works with <applet>/<object>/<embed> HTML tags that are supported by appletviewer and Java Plug-in.
13-11-2006

EVALUATION Name: nl37777 Date: 11/18/2002 This problem can be reduced in at least two ways: - ResourceBundle can provide options to reduce the number of resource bundles tried. For example, some developers have suggested skipping the lookup of class files if it is known that an application only uses properties files. - AppletClassLoader could provide an option to tag a jar file as containing the complete applet. This could, for example, take the form of a flag in the jar file manifest. With this option set, the class loader would immediately fail a class/resource lookup if the class/resource isn't found in the jar file itself, rather than going back to the applet's code base. Possible changes to ResourceBundle are being investigated under RFE 4303146. I'm assigning this to the Plugin team for further evaluation of improvements in the applet class loader. ====================================================================== ###@###.### 2002-11-26 The main cause of this problem is in the ResourceBundle, RFE 4303146 will fix this problem, but it target to Tiger. At this point, our Java plugin can not fix this problem. I will closed this bug as duplicate of 4303146. Dennis Gu ====================================================================== I've reopened this RFE for the portion relating to the AppletClassLoader. 4303146 is for the ResourceBundle portion. Even if 4303146 is implemented, it cannot provide complete relief for the situation described here because there's always a chance that the requested locale in a resource bundle lookup isn't supported by the application, leading to queries for classes and properties files that don't exist. ###@###.### 2003-04-29 Reassign for further evaluation. ###@###.### 2004-11-30 01:36:08 GMT
29-04-2003