This discussion is archived
8 Replies Latest reply: Aug 28, 2012 11:43 AM by thomasng RSS

jre 6 cache structure /  jnlp.versionEnabled not working

924199 Newbie
Currently Being Moderated
Hi,

I have a few specific questions. JNLP experts please help me :)

1. When we moved from 1.5 to java 6 , the way in which jars are cached has changed.
in 1.5 , i was able to clearly identify my application from the cache. But in 1.6 , i see just folders named 0-63. We understand it is for security reasons.
But is it possible to go back to the old structure and still use javaws from 1.6 ??

2. Also i was reading about this feature : CD install of JNLP applications
http://docs.oracle.com/javase/1.5.0/docs/guide/javaws/developersguide/cdinstall.03.06.html

But does it work if i have versioning enabled in my JNLP
     e.g line in my jnlp file
<jar href="jaxb-impl.jar" version="7.5.2.0.1" download="lazy"/>
I get such errors (because in my local disk(codebase attrib) , i had a jar named jaxb-impl__V7_5_2_0_1.jar)

JNLPException[category: Download Error : Exception: java.io.FileNotFoundException: C:\JAR_TEST\signed\jaxb-impl.jar (The system cannot find the file specified) : LaunchDesc: null ]
     at com.sun.javaws.cache.DownloadProtocol.doDownload(Unknown Source)
     at com.sun.javaws.cache.DownloadProtocol.getDownloadSize(Unknown Source)
     at com.sun.javaws.LaunchDownload.downloadJarFiles(Unknown Source)
     at com.sun.javaws.LaunchDownload.downloadEagerorAll(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)

Edited by: user10570461 on Mar 17, 2012 10:56 PM
  • 1. Re: can we control jre 6 cache structure ?
    817264 Journeyer
    Currently Being Moderated
    1. When we moved from 1.5 to java 6 , the way in which jars are cached has changed.
    in 1.5 , i was able to clearly identify my application from the cache. But in 1.6 , i see just folders named 0-63. We understand it is for security reasons.
    But is it possible to go back to the old structure and still use javaws from 1.6 ??

    No.

    Cache internal details are not supposed to be exposed to the end user/app developer.
    They can be changed any time for various reasons.

    Why would you need to identify your app files in the cache?
    May be very is better solution for your scenario.
  • 2. Re: can we control jre 6 cache structure ?
    thomasng Newbie
    Currently Being Moderated
    For 2), yes, you can use the jnlp.versionEnabled property:

    e.g

    <resources>
    ...
    <property name="jnlp.versionEnabled" value="true"/>
    <jar href="draw.jar" version="2.0" main="true" download="eager"/>
    </resources>


    and then have draw__V2.0.jar in your local drive.

    http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/tools/pack200.html
  • 3. Re: can we control jre 6 cache structure ?
    924199 Newbie
    Currently Being Moderated
    The reason we want to identify the app files is to copy them to various desktops / profiles ( distributing to various vendors who access my app).
    we shall lose this feature with jre upgrade on all user desktops.
    Ours is a HUGE app accessed by many users but jnlp based.

    If users from various geographocal locations start downloading the jars at the same time , it would result in
    a. JNLP server crash
    b. network clog
    So if we copy the cache before a release , it helps us.
    But we wont be able to do it anymore after jre upgrade.
  • 4. Re: can we control jre 6 cache structure ?
    924199 Newbie
    Currently Being Moderated
    Thanks a lot .
    I shall try and get back to you
  • 5. Re: can we control jre 6 cache structure ?
    924199 Newbie
    Currently Being Moderated
    I still get the same error inspite of setting the 2 properties
    <property name="jnlp.packEnabled" value="true"/>
    <property name="jnlp.versionEnabled" value="true"/>
    <jar href="abc.jar" version="7.5.2.14.1" />

    PAth:
    abc__V7_5_2_14_1.jar
    abc__V7_5_2_14_1.jar.pack.gz

    java.io.FileNotFoundException: C:\Ram\JAR_TEST\signed\abc.jar (The system cannot find the file specified)
         at java.io.FileInputStream.open(Native Method)
         at java.io.FileInputStream.<init>(Unknown Source)
         at java.io.FileInputStream.<init>(Unknown Source)
         at sun.net.www.protocol.file.FileURLConnection.connect(Unknown Source)
         at com.sun.deploy.net.BasicHttpRequest.doRequest(Unknown Source)
         at com.sun.deploy.net.BasicHttpRequest.doRequest(Unknown Source)
         at com.sun.deploy.net.BasicHttpRequest.doGetRequest(Unknown Source)
         at com.sun.deploy.net.DownloadEngine.actionDownload(Unknown Source)
         at com.sun.deploy.net.DownloadEngine.getCacheEntry(Unknown Source)
         at com.sun.deploy.net.DownloadEngine.getCacheEntry(Unknown Source)
         at com.sun.deploy.net.DownloadEngine.getResourceCacheEntry(Unknown Source)
         at com.sun.deploy.net.DownloadEngine.getResourceCacheEntry(Unknown Source)
         at com.sun.deploy.net.DownloadEngine.getResource(Unknown Source)
         at com.sun.javaws.LaunchDownload$DownloadTask.call(Unknown Source)
         at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
         at java.util.concurrent.FutureTask.run(Unknown Source)
         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
         at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
         at java.lang.Thread.run(Unknown Source)

    From exception tab
    com.sun.deploy.net.FailedDownloadException: Unable to load resource: (file:C:/Ram/JAR_TEST/signed/abc.jar?version-id=7.5.2.14.1, 7.5.2.14.1)
         at com.sun.deploy.net.DownloadEngine.actionDownload(Unknown Source)
         at com.sun.deploy.net.DownloadEngine.getCacheEntry(Unknown Source)
         at com.sun.deploy.net.DownloadEngine.getCacheEntry(Unknown Source)
         at com.sun.deploy.net.DownloadEngine.getResourceCacheEntry(Unknown Source)
         at com.sun.deploy.net.DownloadEngine.getResourceCacheEntry(Unknown Source)
         at com.sun.deploy.net.DownloadEngine.getResource(Unknown Source)
         at com.sun.javaws.LaunchDownload$DownloadTask.call(Unknown Source)
         at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
         at java.util.concurrent.FutureTask.run(Unknown Source)
         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
         at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
         at java.lang.Thread.run(Unknown Source)
  • 6. Re: can we control jre 6 cache structure ?
    955051 Newbie
    Currently Being Moderated
    any updates on this issue,

    so that with 1.6 i will able to see same cache structure of 1.5. i.e jar files are not encrypted
  • 7. Re: can we control jre 6 cache structure ?
    817264 Journeyer
    Currently Being Moderated
    Why do you need versioned files if you distribute your application bypassing javaws download mechanisms?

    Consider using javaws -import -silent to import your application into the cache instead of copying cache directory.
  • 8. Re: can we control jre 6 cache structure ?
    thomasng Newbie
    Currently Being Moderated
    you had the filename convention wrong, it should be . for the version, not _ .

    try:

    abc__V7.5.2.14.1.jar
    abc__V7.5.2.14.1.jar.pack.gz

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points