すべてのユーザーがWebstartアプリケーションを起動しない

Question

起動後にEJBを使用してjbossサーバーに接続するWebstartアプリケーションがあります。私たちは最近、このサーバをjboss5に移行し、それに接続するwebstartアプリケーションを更新しました。今私たちは問題に遭遇しました。デベロッパーマシンでは、webstartsアプリを実行しても問題はありません。起動して接続したり問題を起こすことはありません。しかし、QAテスターのマシンでは、まったく動作しません。ただ起動することができないと言います。 詳細部分では、exceptinはjboss-main-client.jarとjnlpが見つからない間で異なります。しかしラップされた例外は、このことを示しています

java.io.IOException 
      at com.sun.deploy.cache.CacheEntry$9.run(Unknown Source) 
      at java.security.AccessController.doPrivileged(Native Method) 
      at com.sun.deploy.cache.CacheEntry.writeFileToDisk(Unknown Source) 
      at com.sun.deploy.cache.Cache.downloadResourceToTempFile(Unknown Source) 
      at com.sun.deploy.cache.Cache.downloadResourceToCache(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) 

我々はまず、それが署名の問題だったかもしれないと思ったが、それは私たちの地元のdevのマシン上で働いていないでしょう。その後、人のアクセス権に関する質問がありました（これは私の理論です）が、なぜ前のバージョンの仕事はどうでしたか？私たちは1.6 B18とB24、XP、Vista、Windows 7を混在させています。

Answer 1

Javaコンソールでトレースレベルを有効にすると、詳細な例外が見つかることがあります。おそらくそれはネイティブなものです。

Answer 2

JDKソースで見つかりました。

CacheEntry.java、第九PrivilegedExceptionAction.run：

  public Object run() throws IOException { 
       JarFile jar = null; 
       RandomAccessFile raf = null; 

       //reset lengths as they will be updated 
       //and they could be stale (e.g. if we are upgrading from old index file) 
       section2Length = 0; 
       section3Length = 0; 
       section4Length = 0; 
     section4Pre15Length = 0; 
      section4CertsLength = 0; 
      section4SignersLength = 0; 
       section5Length = 0; 
       reducedManifestLength = 0; 
       reducedManifest2Length = 0; 

       try { 
        raf = openLockIndexFile("rw", false); 
        // output index file contents to disk 

        //mandatory header first (will write it again later on) 
        byte header[] = prepareHeader(); 
        raf.write(header); 

        ByteArrayOutputStream bout = new ByteArrayOutputStream(1000); 
        DataOutputStream out = new DataOutputStream(bout); 

        out.writeUTF(getVersion() != null ? getVersion() : ""); 
        out.writeUTF(getURL()); 
        out.writeUTF(getNamespaceID()); 

        // write out resource codebase ip address if available 
        InetAddress ina = null; 

        // get the ip address of the resource codebase 
        String codebase = ""; 
        if (url != null && url.equals("") == false) { 
         URL u = new URL(url); 
         String host = u.getHost(); 
         ina = Cache.getHostIP(host); 
         if (ina != null) { 
          codebase = ina.getHostAddress(); 
         } 
        } 
        out.writeUTF(codebase); 

        // write out HTTP/HTTPS header if available 
        writeHeaders(out); 

        out.close(); 
        bout.close(); 
        section2Length = bout.size(); 
        raf.write(bout.toByteArray()); 

        if (incomplete == 0) { 
         // save sections 3 and 4 (JAR only) 
         if (isJarFile(url)) { 
          jar = new JarFile(new File(filename)); 
          CachedManifest manifest = new CachedManifest(jar); 
          //will update section3Length and section4Length internally 
          writeManifest(raf, jar, manifest, contentType, dd); 
          manifest.postprocess(); //need to do this explicilty 
          updateManifestRefs(manifest); 
          jar.close(); 
         } 
         // this entry just got downloaded, so mark it as update check done 
         DownloadEngine.addToUpdateCheckDoneList(url); 

         // add this entry to the cleanup thread loaded resource list 
         Cache.addToCleanupThreadLoadedResourceList(url); 

         setBusy(0); 
         setIncomplete(0); 
         updateBlacklistValidation(); 
         updateTrustedLibrariesValidation(); 
         doUpdateHeader(raf); 

         //whenether this is jar or not we do not need to try read 
         //manifest or certificates again 
         doneReadManifest = true; 
         doneReadCerts = true; 
         doneReadSigners = true; 
        } 
       } catch (Exception e) { 
        Trace.ignoredException(e); 
        // close file before trying to delete them 
        // set raf/jar to null after closing, so they won't be closed 
        // again in the finally block 
        if (raf != null) { 
         raf.close(); 
         raf = null; 
        } 
        if (jar != null) { 
         jar.close(); 
         jar = null; 
        } 

        Cache.removeCacheEntry(CacheEntry.this); 
        if (e instanceof JARSigningException) { 
         throw (JARSigningException) e; 
        } 
        if (e instanceof java.util.zip.ZipException) { 
         throw new JARSigningException(new URL(url), version, 
           JARSigningException.BAD_SIGNING, e); 
        } 
        throw new IOException(e.getMessage()); 
       } finally { 
        if (raf != null) { 
         raf.close(); 
        } 
        if (jar != null) { 
         jar.close(); 
        } 
        Cache.cleanup(); 
       } 
       return null; 
      } 
     } 

私はにIOExceptionがそれをラップしていなかったので、あなたが本当のエラーを見ていないと思いました。 原因の例外はJavaコンソールに記録されており、表示されていると考えられます。 しかし、そうでない場合は、OpenJDKソースをhttp://download.java.net/openjdk/jdk6/から取得し、このクラス（CacheEntry.java：1681）をデバッグするようにアドバイスしてください。残念ながら、JDKはデバッグ情報なしでビルドされましたが、メソッドにブレークポイントを設定し、デバッガでオブジェクトのプロパティを表示することができます。

Answer 3

それは本当にそのような答えではありませんが、私はJavaでキャッシングの問題を発見しました。キャッシュに入ってキャッシュを削除すると、問題は解決されます。何らかの理由で翌日まで待つこともあります。

Answer 4

ユーザープロファイルがサーバーに格納されている - ユーザーのキャッシュがローカルマシンに存在する場合、異なるWindowsマシンで作業しているユーザーが原因である可能性があります。 が別のマシンに移動すると、webstartアプリはおそらく別のキャッシュフォルダにインストールされます。 javawsの-systemフラグを使用すると助けになるかもしれません。

Answer 5

Ok ... Java 1.7r51が導入されたら、私たちは同じ問題に遭遇しました。 ユーザーはJavaコンソールからキャッシュをクリアしました。 また、「セキュリティ」タブの「例外」セクションにサイトアドレス「https：// ....」を追加しました。 ユーザーが新しいブラウザセッションを開始し、問題なくサイトに接続しました。