Community
Participate
Working Groups
I got this when trying to reproduce bug 49008. - start up the build - import JDT-UI and all required plug-ins as binary projects - import osgi.services (not sure why it wasn't included before) - create new runtime workbench launch config - disable all external plug-ins and features - get the following stack trace on startup osgi> !ENTRY org.eclipse.pde.core 4 4 Dec 17, 2003 11:14:27.892 !MESSAGE Exception caught while creating platform configuration. !STACK 0 java.lang.NullPointerException at java.lang.Throwable.<init>(Throwable.java) at java.lang.Throwable.<init>(Throwable.java:73) at java.lang.NullPointerException.<init>(NullPointerException.java:60) at org.eclipse.pde.internal.core.DefaultRuntimeSupport.getPluginLocation (DefaultRuntimeSupport.java:39) at org.eclipse.pde.internal.core.TargetPlatform.getPluginLocation(Target Platform.java:356) at org.eclipse.pde.internal.core.TargetPlatform.createConfigurationEntri es(TargetPlatform.java:345) at org.eclipse.pde.internal.core.TargetPlatform.savePlatformConfiguratio n(TargetPlatform.java:275) at org.eclipse.pde.internal.core.TargetPlatform.createPlatformConfigurat ionArea(TargetPlatform.java:174) at org.eclipse.pde.internal.ui.launcher.WorkbenchLaunchConfigurationDele gate.getProgramArguments(WorkbenchLaunchConfigurationDelegate.java:138) at org.eclipse.pde.internal.ui.launcher.WorkbenchLaunchConfigurationDele gate.createVMRunner(WorkbenchLaunchConfigurationDelegate.java:86) at org.eclipse.pde.internal.ui.launcher.WorkbenchLaunchConfigurationDele gate.launch(WorkbenchLaunchConfigurationDelegate.java:47) at org.eclipse.debug.internal.core.LaunchConfiguration.launch(LaunchConf iguration.java:156) at org.eclipse.debug.internal.ui.DebugUIPlugin.buildAndLaunch(DebugUIPlu gin.java:740) at org.eclipse.debug.ui.DebugUITools.buildAndLaunch(DebugUITools.java:62 5) at org.eclipse.debug.ui.DebugUITools$3.run(DebugUITools.java:581) at org.eclipse.core.internal.jobs.Worker.run(Worker.java)
Sorry, I should have noted that I am using: build i1216:1717 winxp j9sc1212
Dejan, NPEs with default runtime support has been appearing more and more frequently in all aspects of self-hosting. First, bug 47255 (and many duplicates) and now this. Did you ever figure out what is going on there?
This is just coincidence. IMHO, the real problem is in the runtime - a number of assumptions we made in the past is not true in some situations any more.
We didn't change this code in a while, but we did change the runtime and the startup code and the way we configure what gets to run.
The problem has nothing to do with DefaultRuntimeSupport. Method 'getPluginLocation' crashes because it is given a null. The real cause is in TargetPlatform class, namely in TargetPlatform.createConfigurationEntries. Looks like we are passing bootModel that is null: // Set boot location IPath bootPath = getPluginLocation(bootModel); URL bootURL = new URL("file:" + bootPath.toOSString()); //$NON- NLS-1$
Dejan, I realized that. However, prematurely pointing the finger at you is always fun :-)
I never lost my cool, knowing that I conviniently didn't touch that class for a long time :-).
We still have bug 47255 to worry about though.
The NPE is fixed. When creating the platform.cfg, I was still setting the bootlocation as we did for 2.1, because I was not sure if Dorian needed it for Update. So I played it safe by leaving the platform.cfg unchanged until further notice. However, when launching against an osgi platform, core.boot is not mandatory, so it is possible to launch without it and hence get a null pointer. So when in osgi mode, I no longer set the boot location in platform.cfg because Jeff does not need it, and Dorian informed me that he didnt' either. This NPE never occurs when the target platform is not osgi, because in this case, if core.boot is missing, we don't even launch. In osgi, the mandatory plugins, are the ones we set in the config.ini file. Note that with DJ's setup as described in this bug, you currently still won't be able to launch. You will get past the NPE, but bug 49008 will stop you.
One more thing: org.eclipse.osgi.services was not automatically added to jdt ui's list of prereqs, but no plugin explicity requires it.
