Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4668479

Option to turn off codebase lookup in AppletClassLoader during resource requests



    • Type: Enhancement
    • Status: Resolved
    • Priority: P4
    • Resolution: Fixed
    • Affects Version/s: 1.2.0, 1.3.0, 1.3.1_03, 1.3.1_07, 1.4.0, 1.4.1, 6
    • Fix Version/s: 6
    • Component/s: deploy
    • Labels:
    • Subcomponent:
    • Resolved In Build:
    • CPU:
      generic, x86, sparc
    • OS:
      generic, linux, solaris_8, windows_2000


      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.
      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.
      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:

        -YES- -NO- (buttons

      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
       at java.util.ResourceBundle.getBundleImpl(Unknown Source)
       at java.util.ResourceBundle.getBundle(Unknown Source)



          Issue Links



              stanleyh Stanley Ho (Inactive)
              cprasadsunw Ck Prasad (Inactive)
              0 Vote for this issue
              0 Start watching this issue