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

JWS should have its own cache file management for downloaded resources

XMLWordPrintable

    • Icon: Enhancement Enhancement
    • Resolution: Cannot Reproduce
    • Icon: P4 P4
    • None
    • 1.4.2
    • deploy
    • generic
    • generic

      In the current cache structure implementation, JWS cache downloaded resources,
      such as jnlp file, jar file, etc, using the exact file name downloaded from
      the host. For example, if the jnlp link on the host is http://site/app.jnlp,
      then the downloaded jnlp file will be stored in the name of app.jnlp.

      Such implementation has its limitation. If server is using a servlet to
      dynamically return the jnlp file or resource, JWS will not be able to store
      it.

      There are already several bugs filed due to the limitation of current cache
      management. Such as bug 4794040, 4791692.

      Here is another bug. For JWS testing, we always use a servlet to return
      the jnlp file. This jnlp file is dynamically generated since the j2se tag
      will require a specific Java version. This servlet is taking some query
      arguments and the jnlp file will be generated based on the value.

      Here is one line inside generated jnlp file:
      <jnlp spec="1.0+"
            codebase="http://nasdaq.sfbay:8080/JavawsTest/hellojaws/"
            href="helloservlet.jnlp?TestJRE=1.4.2-beta">

      JWS will have the following exception:
      General:
      An error occurred while launching/running the application.

      Title: Java Web Start Test Case -- Hello Java Web Start
      Vendor: Sun Microsystems, Inc.
      Category: Download Error

      Unable to load resource: http://nasdaq.sfbay:8080/JavawsTest/hellojaws/helloservlet.jnlp?TestJRE=1.4.2-beta

      Exception:
      JNLPException[category: Download Error : Exception: java.io.IOException: Unable to create temp. file for: http://nasdaq.sfbay:8080/JavawsTest/hellojaws/helloservlet.jnlp?TestJRE=1.4.2-beta : LaunchDesc: null ]
      at com.sun.javaws.cache.DownloadProtocol$RetrieveAction.actionDownload(Unknown Source)
      at com.sun.javaws.cache.DownloadProtocol.doDownload(Unknown Source)
      at com.sun.javaws.cache.DownloadProtocol.getLaunchFile(Unknown Source)
      at com.sun.javaws.LaunchDownload.getUpdatedLaunchDesc(Unknown Source)
      at com.sun.javaws.Launcher.downloadResources(Unknown Source)
      at com.sun.javaws.Launcher.handleApplicationDesc(Unknown Source)
      at com.sun.javaws.Launcher.handleLaunchFile(Unknown Source)
      at com.sun.javaws.Launcher.run(Unknown Source)
      at java.lang.Thread.run(Unknown Source)


      I am suggesting a completely new cache structure. Taking Netscape or IE as
      examples, they store downloaded resources (html, image, etc.) using a randomly
      generated file name. They maintain a separate file.db database to have a
      mapping for the URL link and resources stored on the local disk. I believe
      this is the correct approach to handle downloaded resources.

      While this bug is filed for JWS, I think it is also appliable to JPI. JPI is
      currently indexing downloaded class/jar file. I haven't tried to write a
      servlet to return class/jar file dynamically, but I suspect that it will
      be the same result.

      ###@###.### 2003-01-21

            ngthomas Thomas Ng (Inactive)
            nwangsunw Nathan Wang (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

              Created:
              Updated:
              Resolved:
              Imported:
              Indexed: