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.

Bug 121777 - Application on NB platform doesn't start using JWS on Windows/JDK1.5
Summary: Application on NB platform doesn't start using JWS on Windows/JDK1.5
Status: VERIFIED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Module System (show other bugs)
Version: 6.x
Hardware: All Windows XP
: P1 blocker (vote)
Assignee: Jesse Glick
URL:
Keywords: REGRESSION
: 122443 (view as bug list)
Depends on:
Blocks: 79233
  Show dependency tree
 
Reported: 2007-11-12 23:56 UTC by phamernik
Modified: 2008-12-23 08:41 UTC (History)
6 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Exceptions before & after patching LookupCache as well (2.14 KB, text/plain)
2007-11-13 15:35 UTC, Jesse Glick
Details
Working patch (3.32 KB, patch)
2007-11-13 15:41 UTC, Jesse Glick
Details | Diff
Exceptions when using just ModuleSystem patch (10.41 KB, text/plain)
2007-11-14 18:39 UTC, Jesse Glick
Details

Note You need to log in before you can comment on or make changes to this bug.
Description phamernik 2007-11-12 23:56:58 UTC
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.
Comment 1 Jesse Glick 2007-11-13 00:06:30 UTC
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.)
Comment 2 Jaroslav Tulach 2007-11-13 09:14:06 UTC
Č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.
Comment 3 Jesse Glick 2007-11-13 15:11:57 UTC
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.
Comment 4 phamernik 2007-11-13 15:16:34 UTC
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)
....
Comment 5 Jesse Glick 2007-11-13 15:35:42 UTC
Created attachment 52936 [details]
Exceptions before & after patching LookupCache as well
Comment 6 Jesse Glick 2007-11-13 15:41:14 UTC
Created attachment 52937 [details]
Working patch
Comment 7 Jesse Glick 2007-11-13 15:43:35 UTC
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.
Comment 8 Jaroslav Tulach 2007-11-14 14:13:51 UTC
I cannot reproduce anything so far.
Comment 9 Jaroslav Tulach 2007-11-14 16:07:24 UTC
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.
Comment 10 Jesse Glick 2007-11-14 16:53:55 UTC
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.
Comment 11 Jaroslav Tulach 2007-11-14 18:11:16 UTC
> 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.

Comment 12 Jesse Glick 2007-11-14 18:17:24 UTC
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.
Comment 13 Jesse Glick 2007-11-14 18:21:40 UTC
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.
Comment 14 Jesse Glick 2007-11-14 18:39:11 UTC
Created attachment 52995 [details]
Exceptions when using just ModuleSystem patch
Comment 15 Jesse Glick 2007-11-14 18:41:33 UTC
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.
Comment 16 Jesse Glick 2007-11-14 19:15:15 UTC
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.)
Comment 17 Jesse Glick 2007-11-14 19:27:47 UTC
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
Comment 18 Jaroslav Tulach 2007-11-14 20:24:20 UTC
Btw. the XMLFS exception followed by the DataFolder exception is exactly what I have seen when trying to simulate the 
problem.
Comment 19 Jesse Glick 2007-11-14 20:39:55 UTC
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.
Comment 20 phamernik 2007-11-15 00:57:25 UTC
> 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.
Comment 21 Jesse Glick 2007-11-15 04:26:27 UTC
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.
Comment 22 Jaromir Uhrik 2007-11-15 12:50:44 UTC
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.
Comment 23 Jesse Glick 2007-11-15 14:45:44 UTC
Yardo, could you review the patch? Or find someone to do so?
Comment 24 Lukas Hasik 2007-11-16 13:28:30 UTC
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...
Comment 25 Jaroslav Tulach 2007-11-16 16:06:42 UTC
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.
Comment 26 Jesse Glick 2007-11-16 16:32:35 UTC
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?
Comment 27 Jesse Glick 2007-11-16 19:47:05 UTC
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
Comment 28 Jesse Glick 2007-11-16 20:01:14 UTC
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.
Comment 29 Jesse Glick 2007-11-16 20:22:45 UTC
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.
Comment 30 Jesse Glick 2007-11-16 20:35:38 UTC
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
Comment 31 phamernik 2007-11-17 01:36:25 UTC
I just tested my own build created from release60 branch. And can confirm our application works on Windows/JDK1.5 now.
Thanks.
Comment 32 Jesse Glick 2007-11-17 02:08:05 UTC
OK, thanks for report.
Comment 33 Lukas Hasik 2007-11-21 09:20:07 UTC
*** Issue 122443 has been marked as a duplicate of this issue. ***