Webstart app not launching for all users

We have a webstart application that after startup uses EJB's to connect to a jboss server. We recently migrated this server to jboss5 and have update the webstart application that connects to it. Now we have run into a problem. On our developer machines, running the webstarts app there is no problems. Its starts up and connects nor problem. But on the QA testers machines they wont run at all, it just says unable to launch (or something like that). In the details part the exceptin varies between not finding jboss-main-client.jar and the jnlp. But the wrapped exception shows this:

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)

We first thought it might have been a signing issue, but then it would not have worked on our local dev machines. Then there was the question of access rights of the person (which is the theory I have) but then why did th previous version work? We run a mixture of 1.6 B18 to B24 and XP,Vista and Windows 7. Im completely stumped, any ideas?

---

You can try to enable the Trace level in Java Console and there you will find your detailed exception. Probably it's something native.

---

I found it at the JDK source.

CacheEntry.java, the 9th 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;
            }
        }

I thought you didn't see the real error because IOException didn't wrap it. The cause exception is logged in Java Console, and i suppose that it would be visible. But if it isn't so I would advise you to get OpenJDK sources from http://download.java.net/openjdk/jdk6/ and try to debug this class (CacheEntry.java:1681). Unfortunately JDK was built without debug info, but you can set breakpoints at methods and see the object properties with the debugger.

---

Its not really an answer as such, but I found its a caching issue with Java. Once you have gone in and delete the Cache, the problems is solved. Also waiting til the next day help for some reason.

---

The problem is probably caused by users working on different windows machines when the user profile is stored at the server - the user cache resides at the local machine; if he goes to a different machine, the webstart app is probably installed in a different cache folder. using the -system flag of javaws might help

---

Ok... we ran into the same problem, once Java 1.7r51 was introduced. I had the user clear their cache via the Java Console. I also had them add the site address "https://...." to the "Exceptions" section under the "Security" tab. User started a new browser session and connected to the site without a problem.