Community
Participate
Working Groups
Build Identifier: M20091008-1320 Our application runs on top of the Eclipse IDE, and we're seeing NullPointerExceptions in the error log file when the it starts for the first time after installation (or with the -clean option). Besides the exceptions, there seems to be no ill effects, and the exceptions do not occur in subsequent startups. The problem seems to the related to starting bundles programmatically in our application's earlyStartup(IStartup). Our application is starting the following bundles in earlyStartup(): org.mortbay.jetty, org.eclipse.equinox.http.jetty, org.eclipse.equinox.http.registry, com.ibm.nex.3rdparty.spring (spring lib), org.springframework.bundle.osgi.core, org.springframework.bundle.osgi.web, org.springframework.bundle.osgi.extender, org.springframework.bundle.osgi.io, org.eclipse.equinox.servletbridge. This is the exception we're getting in the Error Log: java.lang.NullPointerException at org.eclipse.ui.internal.Workbench.getWorkbenchWindows(Unknown Source) at org.eclipse.ui.internal.ExtensionEventHandler.registryChanged(Unknown Source) at org.eclipse.core.internal.registry.ExtensionRegistry$2.run(Unknown Source) at org.eclipse.core.runtime.SafeRunner.run(Unknown Source) at org.eclipse.core.internal.registry.ExtensionRegistry.processChangeEvent(Unknown Source) at org.eclipse.core.runtime.spi.RegistryStrategy.processChangeEvent(Unknown Source) at org.eclipse.core.internal.registry.osgi.ExtensionEventDispatcherJob.run(Unknown Source) at org.eclipse.core.internal.jobs.Worker.run(Unknown Source) It seems that windowManager is null when the getWorkbenchWindows() function gets called. public IWorkbenchWindow[] getWorkbenchWindows() { Window[] windows = windowManager.getWindows(); IWorkbenchWindow[] dwindows = new IWorkbenchWindow[windows.length]; System.arraycopy(windows, 0, dwindows, 0, windows.length); return dwindows; } Reproducible: Always
Created attachment 184317 [details] Error log file
The easiest fix would be to move windowManager = new WindowManager(); from init() to Workbench.Workbench(Display, WorkbenchAdvisor). This should not have any negative side-effect as the WindowManager constructor does nothing.
(In reply to comment #0) > startups. The problem seems to the related to starting bundles programmatically > in our application's earlyStartup(IStartup). While I'm not against Dani's suggestion to move up the window manager initialization, I don't believe this is the cause of your problem. The IStartup classes are run in org.eclipse.ui.internal.Workbench.startPlugins() after init() is run (which set windowManager). What else is going on in your product to cause this? PW
(In reply to comment #3) > (In reply to comment #0) > > startups. The problem seems to the related to starting bundles programmatically > > in our application's earlyStartup(IStartup). > > While I'm not against Dani's suggestion to move up the window manager > initialization, I don't believe this is the cause of your problem. > > The IStartup classes are run in > org.eclipse.ui.internal.Workbench.startPlugins() after init() is run (which set > windowManager). > > What else is going on in your product to cause this? > > PW (In reply to comment #3) > (In reply to comment #0) > > startups. The problem seems to the related to starting bundles programmatically > > in our application's earlyStartup(IStartup). > > While I'm not against Dani's suggestion to move up the window manager > initialization, I don't believe this is the cause of your problem. > > The IStartup classes are run in > org.eclipse.ui.internal.Workbench.startPlugins() after init() is run (which set > windowManager). > > What else is going on in your product to cause this? > > PW You're right, it's not related to code in IStartup. Sorry, it's been awhile since I looked at the code. In our UIPlugin bundle's start() function, we're also programmatically installing and starting two other bundles (this probably triggered the call to getWorkbenchWindows() prematurely); this was our workaround for not being able to figure out why OSGi is not recognizing these two bundles. The exception went away when this call is commented out. Thanks, Ryan
(In reply to comment #4) >The exception went away when this call is commented out. OK to close then?
(In reply to comment #5) > (In reply to comment #4) > >The exception went away when this call is commented out. > OK to close then? Unfortunately, we still need this call; it was commented out to help identify the cause. This does provide us with a solution - to delay this call by calling it in the earlyStartup(); however, this is not favorable since it would increase wait time (after the IDE is up) for the availability of the web services that are provided by the programmatically installed bundles.
(In reply to comment #6) > Unfortunately, we still need this call; it was commented out to help identify > the cause. This does provide us with a solution - to delay this call by calling > it in the earlyStartup(); however, this is not favorable since it would > increase wait time (after the IDE is up) for the availability of the web > services that are provided by the programmatically installed bundles. I'm not convinced moving this call up is a good idea. While the window manager construction is harmless, the gist of the problem is the Workbench is being accessed before the workbench has been fully initialized. Removing the NPE could simply allow the code to continue, doing things incorrectly. It's possible to replace the offending code in ExtensionEventHandler with: Display display = PlatformUI.getWorkbench().getDisplay(); But once again, with the workbench not fully initialized, any changes that are to be processed by this will be thrown away, or half processed. PW
>I'm not convinced moving this call up is a good idea. From an API/client perspective throwing an NPE is not expected hence fixing this seems right, even though it does not guaranteed that the client works afterwards. The client should use the Workbench.is* methods to check the state.
Created attachment 186093 [details] safe up NPE locations v01 I safed up getWorkbenchWindows() and getWorkbenchWindowCount() so they won't NPE, and simply got the Display from PlatformUI.getWorkbench().getDisplay() in ExtensionEventHandler. rpham, could you test this solves your problem? PW
Released to HEAD PW
I the installed plugins in I20110124-1800 PW
*** Bug 356487 has been marked as a duplicate of this bug. ***
