This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Java web start fails to start Suite project based on NetBeans 6.0. Unfortunately this is blocker for us as we cannot use latest NB 6.0 builds for our application. Environment where I tested it: - Windows XP (maybe also Vista?) - JDK 1.5.0_13 (also tested on _12) - NetBeans platform beta2 or newer (Note: It worked fine with NB 6.0 beta1) The simplest way how to reproduce it: 1. New project -> NetBeans Modules -> Module Suite 2. Select the suite, go to properties 3. -> Libraries -> leave only platform7 selected 4. -> Build -> select "Create Standalone Application" 5. r-click on suite -> Run JNLP application => application is loaded and during splash screen you get the following exception and whole application is closed: java.lang.IllegalArgumentException: URI is not hierarchical at java.io.File.<init>(Unknown Source) at org.netbeans.core.startup.ModuleSystem.loadBootModules(ModuleSystem.java:210) at org.netbeans.core.startup.Main.getModuleSystem(Main.java:169) at org.netbeans.core.startup.Main.start(Main.java:322) at org.netbeans.core.startup.TopThreadGroup.run(TopThreadGroup.java:110) [catch] at java.lang.Thread.run(Unknown Source) I tried to debug what URLs are wrong and got this jar's URL: file:C:/Documents%20and%20Settings/Petr%20Hamernik/Application%20Data/Sun/Java/Deployment/cache/javaws/file/D/P-1/DMC&c/DMtemp/DMsuite2/DMdist/DMjnlp/DMlocal/DMbranding/RMcore_suite2.jar!/META-INF/ As you can see the slash is missing there. The correct URL shoudl start with file:/C:/... The bug seems to be in com.sun.jnlp.JNLPClassLoader in JDK 1.5, but could be fixed in NetBeans. It worked fine in older versions, at least we are sure it worked in beta1. As I said before we cannot use latest NetBeans with this bug as our customers are using Windows/JDK1.5.
Not pnejedly's code; probably introduced by fix of issue #79233. (phamernik was probably thinking of a probably unrelated issue, which is that JarClassLoader uses the deprecated and dangerous File.toURL() as a result of a recent commit by pnejedly. But JCL is not used in JNLP mode, I think.)
Čau Petře, can you try to rollback diff in issue 79233 to see if that improves the behaviour you are observing? If not, then let me know, otherwise we wait for Jesse to fix that.
It is reproducible, and a simple fix to the fix of issue #79233 makes this exception not happen. Unfortunately, there is then a similar exception in LookupCache. I am still investigating.
yes, I think I have seen when I used older NB platform (M10). It was: java.lang.IllegalArgumentException: URI is not hierarchical at java.io.File.<init>(Unknown Source) at org.netbeans.core.LookupCache$1.run(LookupCache.java:249) at org.openide.util.Mutex.readAccess(Mutex.java:296) at org.netbeans.core.LookupCache.relevantFiles(LookupCache.java:221) at org.netbeans.core.LookupCache.cacheHit(LookupCache.java:142) at org.netbeans.core.LookupCache.load(LookupCache.java:86) at org.netbeans.core.CoreBridgeImpl.lookupCacheLoad(CoreBridgeImpl.java:96) at org.netbeans.core.startup.CoreBridge.conditionallyLookupCacheLoad(CoreBridge.java:57) ....
Created attachment 52936 [details] Exceptions before & after patching LookupCache as well
Created attachment 52937 [details] Working patch
So the problem in ModuleSystem can be fixed easily enough. The problem in LookupCache I thought could also be fixed easily, and the attached patch tries to do so. However NB then throws a different exception indicating that layer content is not properly initialized. I am not sure I understand the code in LookupCache well enough to make fixes here, so passing to Yarda for that part.
I cannot reproduce anything so far.
Sorry, guys, I've got only: Caused: java.io.IOException: jar:file:C:/Documents%20and%20Settings/Tomas/Application%20Data/Sun/Java/Deployment/cache/javaws/file/D/P-1/DMC&c/DMDocuments&p20and&p20Settings/DMTomas/DMMy&p20Documents/DMNetBeansProjects/DMPaintApp1/DMdist/DMjnlp/DMlocal/DMnetbeans/DMorg-netbeans-api-progress/RMorg-netbeans-api-progress.jar!/org/netbeans/progress/module/resources/layer.xml at org.openide.filesystems.XMLFileSystem.setXmlUrls(XMLFileSystem.java:348) at org.openide.filesystems.XMLFileSystem.setXmlUrls(XMLFileSystem.java:283) at org.netbeans.core.startup.layers.NonCacheManager.store(NonCacheManager.java:84) at org.netbeans.core.startup.layers.ModuleLayeredFileSystem$1.run(ModuleLayeredFileSystem.java:311) at org.openide.filesystems.EventControl.runAtomicAction(EventControl.java:120) at org.openide.filesystems.FileSystem.runAtomicAction(FileSystem.java:499) at org.netbeans.core.startup.layers.ModuleLayeredFileSystem.setURLs(ModuleLayeredFileSystem.java:301) at org.netbeans.core.startup.layers.ModuleLayeredFileSystem.addURLs(ModuleLayeredFileSystem.java:374) at org.netbeans.core.startup.NbInstaller.loadLayers(NbInstaller.java:557) at org.netbeans.core.startup.NbInstaller.load(NbInstaller.java:262) at org.netbeans.ModuleManager.enable(ModuleManager.java:933) at org.netbeans.core.startup.ModuleList.installNew(ModuleList.java:405) at org.netbeans.core.startup.ModuleList.trigger(ModuleList.java:341) at org.netbeans.core.startup.ModuleSystem.restore(ModuleSystem.java:275) at org.netbeans.core.startup.Main.getModuleSystem(Main.java:171) at org.netbeans.core.startup.Main.start(Main.java:322) at org.netbeans.core.startup.TopThreadGroup.run(TopThreadGroup.java:110) and there is nothing about any LookupCache.
Can you not reproduce the original exception, when running without my patch? Or do you just mean that after applying my patch you cannot reproduce any problems with the lookup cache? If the latter, I don't know what to do other than ask other people to check as well. I cannot recommend a patch for merging if I cannot make it work for myself.
> Can you not reproduce the original exception, when running without my patch? That one has been reproduced. > Or do you just mean that after applying my > patch you cannot reproduce any problems with the lookup cache? We applied just part of your patch - the one in core/startup. And yes, after applying that patch, I am seeing only: java.io.IOException: jar:file:C:/Documents%20and%20Settings/Tomas/Application%20Data/Sun/Java/Deployment/cache/javaws/file/D/P-1/DMC&c/DMDocuments&p20and&p20Settings/DMTomas/DMMy&p20Documents/DMNetBeansProjects/DMPaintApp1/DMdist/DMjnlp/DMlocal/DMnetbeans/DMorg-netbeans-api-progress/RMorg-netbeans-api-progress.jar!/org/netbeans/progress/module/resources/layer.xml at org.openide.filesystems.XMLFileSystem.setXmlUrls(XMLFileSystem.java:348) at org.openide.filesystems.XMLFileSystem.setXmlUrls(XMLFileSystem.java:283) > If the latter, I don't know what to do other than ask > other people to check as well. I cannot recommend a patch for merging > if I cannot make it work for myself. Well, I do not feel comfortable fixing something caused by issue 79233 which is just full of magicfull "engineering" to me. You know what your intent with issue 79233 was, so I rely on you to cure the symptoms. On the other hand, given this is P1 bug, I would suggest to revert 79233 completely or at least disable it when running in JNLP mode (probably can be tested by Installer.class.getClassLoader() == NbInstaller.class.getClassLoader()) for release 6.0.
I have not seen the exception Yarda shows here (note that the root cause has been omitted, so I don't know the actual problem); this would be yet another place (NbInstaller.loadLayers) where ClassLoader.getResource{,s} is called and produces a bogus result.
The change in issue #79233 was quite straightforward, and the patch in core/startup AFAIK successfully works around the symptoms of the JRE bug in that class. I am not worried about that part. I am worried about the fact that other parts of the platform - layer loading and caching - also seem to be broken under JDK 5 javaws. Reporter says everything "worked fine" in M10 but also admits that he saw the exception in LookupCache.
Created attachment 52995 [details] Exceptions when using just ModuleSystem patch
Correction: on a new suite I get an exception from XMLFileSystem (complete stack trace is in log file attached), which then later probably causes the IAE in DataFolder.findFolder, which is all I saw in the exception dialog (you only get a few seconds to review it, unlike the log file). So it seems there are at least three places where NB code runs into the problem: ModuleSystem, LookupCache, and XMLFileSystem.
Note that - confusingly - JWS is set up in such a way that it is possible to run ...\jdk15\jre\bin\javaws and have ...\jdk15\jre\lib\deploy.jar in the app CP, yet nonetheless be using ...\jdk16\jre\lib\rt.jar as the boot classpath! So checking for Java 6 does not suffice; it matters what version of javaws is being used, not what JRE. (I have spent some time playing with the Java Control Panel attempting to get Java 5 javaws to use Java 5's rt.jar, without success; if you disable the Java 6 JRE, you get weird error dialog boxes when trying to launch, and nothing works.)
I believe the following patch fixes it, but I would want verification both from reporter and QE before considering a merge to release60. There may be other, as yet undiscovered, problems arising from the javaws bug. Also, I would want a clear explanation of how an app could have run successfully with the known problems in XMLFileSystem and LookupCache - as far as I know only the ModuleSystem problem was introduced recently (from issue #79233). Checking in openide/fs/src/org/openide/filesystems/XMLFileSystem.java; /shared/data/ccvs/repository/openide/fs/src/org/openide/filesystems/XMLFileSystem.java,v <-- XMLFileSystem.java new revision: 1.21; previous revision: 1.20 done Checking in core/src/org/netbeans/core/LookupCache.java; /shared/data/ccvs/repository/core/src/org/netbeans/core/LookupCache.java,v <-- LookupCache.java new revision: 1.16; previous revision: 1.15 done Checking in core/startup/src/org/netbeans/core/startup/ModuleSystem.java; /shared/data/ccvs/repository/core/startup/src/org/netbeans/core/startup/ModuleSystem.java,v <-- ModuleSystem.java new revision: 1.17; previous revision: 1.16 done
Btw. the XMLFS exception followed by the DataFolder exception is exactly what I have seen when trying to simulate the problem.
It seems that the ModuleSystem and XMLFileSystem problems, if not patched against, happen on every start; whereas the LookupCache problem happens on second and subsequent starts only.
> I believe the following patch fixes it, but I would want verification both from reporter I can confirm that the current trunk version (Hudson #4437) works for me. I tested to run our app on top of this NB build a few times with JWS JDK1.5 and it started always without problems. I tried to run it with manually cleared cache of local JWS as well as start with cached jars. All works fine now. I also quickly tested JWS 1.6, just to be sure. So from my point of view the patch fixes the problem. We will continue testing tomorrow.
Patch, for reference: http://deadlock.netbeans.org/fisheye/rdiff/netbeans?csid=MAIN:jglick:20071114192529&u&N Be sure to test with the app deployed to a web server, as URLs produced by the javaws cache when loading against http protocol rather than file protocol might be of a different form. Also make sure that changes to module layers are correctly reflected in the following runs.
I have verified it in trunk build #200711150000. I even tried to run the FeedReader from the server (but first I had to edit codebase property in all .jnlp files of the project's dist/jnlp subfolders - see enhancement #121987). The exception didn't appear during my testing so that it should go to 6.0 branch.
Yardo, could you review the patch? Or find someone to do so?
verified by QE in trunk Product Version: NetBeans IDE Dev (Build 200711160000) Java: 1.5.0_11; Java HotSpot(TM) Client VM 1.5.0_11-b03 System: Windows XP version 5.1 running on x86; Cp1250; cs_CZ (nb) There is still missing review here...
Patch in XMLFileSystem just adds catch IllegalArgumentException - e.g. can only improve behaviour by swallowing some exceptions. Patch in LookupCache seems to add file:/ where only file: was present. Here I miss a test. The patch in ModuleSystem seems to ignore all file: that are not followed with /. Magic to me, but very likely this fixes something, especially if the reported confirmed that he does no longer see the behaviour he used to see.
The affected code in ModuleSystem was part of an optimization to speed up startup a bit. If it gets file:c:... URLs it now simply disables the optimization. The optimization has been there a long time; formerly it was rather complicated and had at least one problem, which is why it was simplified in issue #79233. Test for LookupCache - possible, if I can find the time. There is none that I can find now, so a fresh one would have to be written. Still missing information: 1. Why could Petr use M10, when that presumably had the problems in LookupCache and XMLFileSystem? 2. Is there a bug already filed for javaws, and if so, will it be fixed in some JDK 5 update?
LookupCache patch tested: Checking in test/unit/src/org/netbeans/core/LookupCacheTest.java; /shared/data/ccvs/repository/core/test/unit/src/org/netbeans/core/LookupCacheTest.java,v <-- LookupCacheTest.java initial revision: 1.1 done Checking in nbproject/project.xml; /shared/data/ccvs/repository/core/nbproject/project.xml,v <-- project.xml new revision: 1.34; previous revision: 1.33 done
http://bugs.sun.com/view_bug.do?bug_id=5076633 It is not so much that the bug with the slash was fixed directly, but that JDK 6 javaws is now returning a totally different URL (either a legitimate file URL, or an http URL). I would not expect such a major change to be backported to JDK 5.
I can confirm that JNLP platform apps work without apparent problems on JDK 5 / Win 32 when run from NB 6 M10. I have no idea why the LookupCache & XMLFileSystem problems do not appear in this case, but I don't think I have time to investigate.
Merged to release60: Checking in openide/fs/src/org/openide/filesystems/XMLFileSystem.java; /shared/data/ccvs/repository/openide/fs/src/org/openide/filesystems/XMLFileSystem.java,v <-- XMLFileSystem.java new revision: 1.20.4.1; previous revision: 1.20 done Checking in core/startup/src/org/netbeans/core/startup/ModuleSystem.java; /shared/data/ccvs/repository/core/startup/src/org/netbeans/core/startup/ModuleSystem.java,v <-- ModuleSystem.java new revision: 1.16.4.1; previous revision: 1.16 done Checking in core/src/org/netbeans/core/LookupCache.java; /shared/data/ccvs/repository/core/src/org/netbeans/core/LookupCache.java,v <-- LookupCache.java new revision: 1.15.6.1; previous revision: 1.15 done
I just tested my own build created from release60 branch. And can confirm our application works on Windows/JDK1.5 now. Thanks.
OK, thanks for report.
*** Issue 122443 has been marked as a duplicate of this issue. ***