Community
Participate
Working Groups
Here's the stack trace: java.lang.NullPointerException at org.eclipse.ptp.rdt.ui.wizards.RemoteProjectContentsLocationArea.populateConnectionCombo(RemoteProjectContentsLocationArea.java:302) at org.eclipse.ptp.rdt.ui.wizards.RemoteProjectContentsLocationArea.handleServicesSelected(RemoteProjectContentsLocationArea.java:288) at org.eclipse.ptp.rdt.ui.wizards.RemoteProjectContentsLocationArea.access$0(RemoteProjectContentsLocationArea.java:285) at org.eclipse.ptp.rdt.ui.wizards.RemoteProjectContentsLocationArea$1.widgetSelected(RemoteProjectContentsLocationArea.java:353) at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:234) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1053) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4066) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3657) at org.eclipse.jface.window.Window.runEventLoop(Window.java:825) at org.eclipse.jface.window.Window.open(Window.java:801) at org.eclipse.ui.internal.navigator.wizards.WizardShortcutAction.run(WizardShortcutAction.java:98) at org.eclipse.jface.action.Action.runWithEvent(Action.java:498) at org.eclipse.jface.action.ActionContributionItem.handleWidgetSelection(ActionContributionItem.java:584) at org.eclipse.jface.action.ActionContributionItem.access$2(ActionContributionItem.java:501) at org.eclipse.jface.action.ActionContributionItem$5.handleEvent(ActionContributionItem.java:411) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:84) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1053) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:4066) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3657) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2629) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2593) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2427) at org.eclipse.ui.internal.Workbench$7.run(Workbench.java:670) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:332) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:663) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:115) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:196) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:369) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:600) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:619) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:574) at org.eclipse.equinox.launcher.Main.run(Main.java:1407) at org.eclipse.equinox.launcher.Main.main(Main.java:1383) This is related to bug 319128. RSEServices might get partially initialized if RSECorePlugin initialization has not been completed (see RSEServices.initialize()). RemoteServicesProxy.loadServices() will only initialize the associated IRemoteServices delegate if RemoteServicesProxy does not have one already. If RSECorePlugin has not been loaded, the delegate will be created but not fully initialized. I think RemoteServicesProxy.loadServices() should test its delegate to see if the delegate has been initialized and if it isn't then it should initialize the delegate. Another problem is that RSE might not get initialized at all and in this case, RSEServices should kick off the RSE initialization. RSEServices would have to wait for the initialization to complete and while it waits, Chris suggests we can put up a dialog in case user does not want to wait or if RSE initialization somehow gets stuck.
I changed this somewhat for HEAD to try and avoid the initialization problems. Can you take a look at the latest code to see if it solves the problem?
(In reply to comment #1) > I changed this somewhat for HEAD to try and avoid the initialization problems. > Can you take a look at the latest code to see if it solves the problem? I couldn't reproduce the problem I saw on HEAD anymore. Can your change be backported to 4.0.x branch? Also, would we need the following changes to RemoteServicesProxy.loadServices()? ### Eclipse Workspace Patch 1.0 #P org.eclipse.ptp.remote.core Index: src/org/eclipse/ptp/remote/internal/core/RemoteServicesProxy.java =================================================================== RCS file: /cvsroot/tools/org.eclipse.ptp/core/org.eclipse.ptp.remote.core/src/org/eclipse/ptp/remote/internal/core/RemoteServicesProxy.java,v retrieving revision 1.9 diff -u -r1.9 RemoteServicesProxy.java --- src/org/eclipse/ptp/remote/internal/core/RemoteServicesProxy.java 28 Mar 2011 15:00:23 -0000 1.9 +++ src/org/eclipse/ptp/remote/internal/core/RemoteServicesProxy.java 25 Apr 2011 13:39:51 -0000 @@ -141,6 +141,8 @@ if (factory != null) { fDelegate = factory.getServices(this); } + } else if (!fDelegate.isInitialized()) { + fDelegate.initialize(); } } }
I don't think this can be backported because it required API changes. In HEAD, you should be calling either one of the PTPRemoteUIPlugin#getRemoteServices() methods (or the PTPRemoteCorePlugin#getRemoteServices() methods that take IProgressMonitor arguments.) These methods ensure that the remote service provider is initialized before returning. I would suggest providing your own implementation of PTPRemoteUIPlugin#getRemoteServices(). The patch is not required as initialization is taken care of if one of the above methods is used.
(In reply to comment #3) > I don't think this can be backported because it required API changes. In HEAD, > you should be calling either one of the PTPRemoteUIPlugin#getRemoteServices() > methods (or the PTPRemoteCorePlugin#getRemoteServices() methods that take > IProgressMonitor arguments.) These methods ensure that the remote service > provider is initialized before returning. I would suggest providing your own > implementation of PTPRemoteUIPlugin#getRemoteServices(). > > The patch is not required as initialization is taken care of if one of the > above methods is used. I found that even if I have my own implementation of PTPRemoteUIPlugin#getRemoteServices(), I'd still need to add getRemoteServices() method that take IProgressMonitor argument in PTPRemoteCorePlugin (unless I change the behaviour of existing PTPRemoteCorePlugin #getRemoteServices() so that the services will be initialized). I was looking at bug 320113 and looks like there should be changes in the ptp_4_0 branch for PTPRemoteCorePlugin to initialize the services but I couldn't find the changes.
*** Bug 394451 has been marked as a duplicate of this bug. ***
I'm assuming this won't be fixed as development has shifted to JSch/sync projects.
