| Summary: | Java WebStart support is broken with J2SE 6.0 | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Jason Hao <jason.hao> |
| Component: | Runtime | Assignee: | platform-runtime-inbox <platform-runtime-inbox> |
| Status: | RESOLVED WORKSFORME | QA Contact: | |
| Severity: | blocker | ||
| Priority: | P3 | CC: | dmcreynolds, jeffmcaffer, nicolas.richeton, tom.huybrechts |
| Version: | 3.3 | ||
| Target Milestone: | 3.3 M4 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
|
Description
Jason Hao
Which version of osgi are you using, 3.2 or 3.2.1? (In reply to comment #1) > Which version of osgi are you using, 3.2 or 3.2.1? > I play with 3.2.1. I know there's another bug(162097) in 3.2.1. So I modified the jar file names to make 3.2.1 happy. For example, I changed org.eclipse.osgi_3.2.1.R32x_v20060919.jar to org.eclipse.osgi_3.2.1.R32x.v20060919.jar. In J2SE 6.0 document, it mentioned, "The format of the cache is completely changed and should never be assumed. Any existing code that assumed the previous format of the cache, for either Java Web Start or Java Plug-in will no longer work.". (http://java.sun.com/javase/6/docs/technotes/guides/javaws/enhancements6.html). It should be the root cause. I wonder if there's an expected date for the fix. I also have this problem. My app was working perfectly unsing webstart and Java 1.5 I tried with Java 6 and it doesn't work. Packages are downloaded but the launch fails. Log : !ENTRY org.eclipse.update.configurator 2006-12-11 10:19:31.963 !MESSAGE C:\Documents and Settings\niric\Application Data\Sun\Java\Deployment\cache\javaws\http\Dsharemedia.free.fr\P80\DMwebstart\plugins is not a valid plugins directory. WebStartMain have to be updated with new jar caching system of Java 6 I'm using Eclipse 3.3M3 The solution consists in adding the following line to the main jnlp file:
<property name="eclipse.webstart.preciseBundleId" value="true"/>
I will update the doc and change the code such that setting this property is done automatically in the code.
Fixed for M4. When java 6 is detected eclipse.webstart.preciseBundleId is automatically set to true since it can't work otherwise. you want to do this change in 3.2.2 as well? Yes because the change is trivial (check the version of the vm we are running against and if it is greater than 1.6 then set preciseBundleId to true). I tried 3.3 M4 and I got following exception. !MESSAGE Exception launching the Eclipse Platform: !STACK java.lang.ClassNotFoundException: org.eclipse.core.runtime.adaptor.EclipseStarter at java.net.URLClassLoader$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at org.eclipse.core.launcher.Main.invokeFramework(Main.java:336) at org.eclipse.core.launcher.Main.basicRun(Main.java:283) at org.eclipse.core.launcher.WebStartMain.basicRun(WebStartMain.java:61) at org.eclipse.core.launcher.Main.run(Main.java:984) at org.eclipse.core.launcher.WebStartMain.main(WebStartMain.java:40) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at com.sun.javaws.Launcher.executeApplication(Unknown Source) at com.sun.javaws.Launcher.executeMainClass(Unknown Source) at com.sun.javaws.Launcher.doLaunchApp(Unknown Source) at com.sun.javaws.Launcher.run(Unknown Source) at java.lang.Thread.run(Unknown Source) After debugged org.eclipse.core.launcher.Main.class, I found addEntry(URL url, List result) method always failed since the URL is http scheme in J2SE 6.0, which result in StartupClassLoader had an empty class path. Reopen this bug according to comments #10. For the 3.2.2 stream, I have attached a pre-built version of the startup.jar in bug #169691. This jar should also work for people running on 3.3 M4. I'll work on a patch for 3.3. Don't if this adds any to the knowledge base for this bug, but using 3.2.2 and Java 1.6 with jnlp set to: <jnlp spec="1.0+" codebase="http://briones/ief" href="workbench.jnlp"> I get the following error, indicating a very odd URL for looking back at the configuration area (even though updater plugin successfully wrote to the configuration area): !ENTRY org.eclipse.update.configurator 2007-03-05 16:13:55.015 !MESSAGE ConfigurationParser.parse() error: !STACK 0 java.io.IOException: Server returned HTTP response code: 403 for URL: http://briones/C:/ief/configuration/org.eclipse.update/platform.xml at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source) at java.net.URL.openStream(Unknown Source) at org.eclipse.update.internal.configurator.ConfigurationParser.parse(ConfigurationParser.java:73) at org.eclipse.update.internal.configurator.PlatformConfiguration.loadConfig(PlatformConfiguration.java:1057) at org.eclipse.update.internal.configurator.PlatformConfiguration.initializeCurrent(PlatformConfiguration.java:736) at org.eclipse.update.internal.configurator.PlatformConfiguration.<init>(PlatformConfiguration.java:102) at org.eclipse.update.internal.configurator.PlatformConfiguration.startup(PlatformConfiguration.java:680) This problem is not related to java 6, but is coming from the fact that update configurator is not jws friendly. Given that the role of update.configurator is to discover plug-ins on disk and that in the jws this discovery is implicitly done by jws (by giving the list of jars from the jnlp files), update.configurator should simply not be started in your configuration. |