Community
Participate
Working Groups
Build ID: RSE 3.4m5 When running on Eclipse 4.2m5, as soon as I make a connection in RSE, I see following message and stacktrace printed ... it looks like storing passwords is not possible out of the box in 4.2 any more. This must be considered a major issue for Juno since 4.2 is the designated release train version. Plus, the core.runtime.compatibility.auth bundle is not available on the Eclipse Platform 4.2 p2 repository so end users won't get it easily. !ENTRY org.eclipse.core.runtime 2 0 2012-01-31 17:05:51.738 !MESSAGE Authorization infrastructure (org.eclipse.core.runtime.compatibility.auth) not installed. !STACK 0 java.lang.ClassNotFoundException: org.eclipse.core.internal.runtime.auth.AuthorizationDatabase at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:501) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:421) at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:412) at org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:107) at java.lang.ClassLoader.loadClass(ClassLoader.java:248) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:169) at org.eclipse.core.internal.runtime.AuthorizationHandler.getAuthClass(AuthorizationHandler.java:51) at org.eclipse.core.internal.runtime.AuthorizationHandler.loadKeyring(AuthorizationHandler.java:72) at org.eclipse.core.internal.runtime.AuthorizationHandler.getAuthorizationInfo(AuthorizationHandler.java:265) at org.eclipse.core.runtime.Platform.getAuthorizationInfo(Platform.java:621) at org.eclipse.rse.core.PasswordPersistenceManager.getPasswordMap(PasswordPersistenceManager.java:340) at org.eclipse.rse.core.PasswordPersistenceManager.find(PasswordPersistenceManager.java:518) at org.eclipse.rse.core.PasswordPersistenceManager.find(PasswordPersistenceManager.java:398) at org.eclipse.rse.core.PasswordPersistenceManager.passwordExists(PasswordPersistenceManager.java:262) at org.eclipse.rse.core.PasswordPersistenceManager.passwordExists(PasswordPersistenceManager.java:247) at org.eclipse.rse.core.subsystems.AuthenticatingConnectorService.hasPassword(AuthenticatingConnectorService.java:115) at org.eclipse.rse.internal.ui.actions.SystemClearPasswordAction.checkObjectType(SystemClearPasswordAction.java:64) at org.eclipse.rse.ui.actions.SystemBaseAction.updateSelection(SystemBaseAction.java:535) at org.eclipse.rse.ui.actions.SystemBaseAction.setSelection(SystemBaseAction.java:449) at org.eclipse.rse.ui.actions.SystemBaseAction.setInputs(SystemBaseAction.java:358) at org.eclipse.rse.internal.ui.view.SystemView.fillContextMenu(SystemView.java:1144) at org.eclipse.rse.internal.ui.view.SystemView.menuAboutToShow(SystemView.java:1167) at org.eclipse.jface.action.MenuManager.fireAboutToShow(MenuManager.java:342) at org.eclipse.jface.action.MenuManager.handleAboutToShow(MenuManager.java:473) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.e4.ui.workbench.renderers.swt.MenuManagerRendererFilter.showMenu(MenuManagerRendererFilter.java:253) at org.eclipse.e4.ui.workbench.renderers.swt.MenuManagerRendererFilter.handleShow(MenuManagerRendererFilter.java:225)
When Eclipse Platform first started building the 4.x SDK, they omitted any compatibility code that supported migration from 2.1 to 3.0, as long as it didn't remove any API. Supporting migration from 2.x directly to 4.x seemed like overkill. We've done similar things in the 3.x stream, such as removing org.eclipse.core.resources.compatibility at some point (bug 336129). The old API for passwords has been deprecated for many years, replaced with Equinox secure storage. The old API has long been a source of problems for people because it includes cryptographic code (bug 121997). It is also inherently insecure because it relies on the user setting a password on the command line, which nobody ever does. If somebody really wants the old implementation, they can add the fragment back. It's available in the 3.8 p2 repository. The old API hasn't actually been deleted in this case, but I think it probably should be (bug 370248). Migration docs will be written for this in 4.2 (bug 370247). Looks like in TM, we should look at adopting Equinox secure storage, though we'll probably need to consider migration of old workspaces with saved passwords too. Bug 225320 is open for migrating TM to Equinox Secure Storage.
