Community
Participate
Working Groups
Created attachment 87270 [details] Sample plugin made from Sample View template that prints system registry value on startup Build ID: Build ID: M20071023-1652 Steps To Reproduce: If SystemStartHere.getSystemRegistry() is called when RSEUIPlugin has not been started, then it returns null since the only place where registry is initialized is start() method of RSEUIPlugin.
Essentially, this issue arises because in the RSE 2.x timeframe, only the ISystemRegistry APIs were split between UI and non-UI while the implementation had to be kept in the UI space due to lack of time. In the RSE 3.x time frame, we will move the SystemRegistry implementation into non-UI as well, so by then you should be safe doing SystemStartHere.getSystemRegistry() and everything you can do from the interface you get should work safely -- without any unnecessary plugin activations. Until these refactorings are complete, the correct way of initializing RSE in the 2.x stream is documented in bug 202040 comment 1. Since this * is only an implementation issue and not a user-visible issue, * there is a workaround available, * and the workaround is no worse than what we had in RSE 1.x This can be considered an enhancement rather than critical bug. Admittedly, it is an API breakage and thus regression compared to RSE 1.x but this is documented by doing a major version rev up.
Created attachment 89532 [details] Patch making the change Attached patch makes the change. Following Breaking API and User Interface changes were required: ---------------------------------------------------------------- * Moved methods from ISystemRegistry into ISystemRegistryUI: public boolean getQualifiedHostNames(); public void setQualifiedHostNames(boolean set); public void setShowFilterPools(boolean show); public void setShowNewHostPrompt(boolean show); * ISystemRegistry.setSystemProfileActive() no longer shows a dialog warning about potential problems, but just logs to the error log -- Returning a MultiStatus from the call should be considered to give better access to the warnings * SystemRegistry logfile is now in RSECorePlugin and no longer RSEUIPlugin * Removed RSECorePlugin.setSystemRegistry(ISystemRegistry); Following backward compatible changes were also made: ----------------------------------------------------- * Messages from systemmessages.xml now duplicated in RSECoreMessages: RSEG1069, RSEG1073, RSEG1075, RSEG1081 -- Removing these from systemmessages.xml should be considered. * Added new public methods in RSECorePlugin: + static ISystemProfileManager getTheSystemProfileManager() + static boolean isTheSystemRegistryActive() * Deprecated methods in RSEUIPlugin: - getPersistenceManager(); - getTheSystemProfileManager(); - isSystemRegistryActive(); - isTheSystemRegistryActive(); Other notes: ------------ * For SystemRegistry.getRemoteObjectIdentifier() we should consider creating adapter factories that provide the IRemoteObjectIdentifier adapters without loading the UI factories -- either by having objects like RemoteFile implement IRemoteObjectIdentifier directly, or by providing non-UI adapter factories for it. Currently, this code only works when UI plugins are loaded, which is not optimal. * The InitRSEJob should be moved from RSEUIPlugin into RSECorePlugin in order to ensure proper system setup even in the non-UI case.
Patch committed: [215820] Move SystemRegistry implementation to Core
(In reply to comment #2) Here is one more breaking change: * org.eclipse.rse.core plugin now has a dependency on org.eclipse.swt (in its MANIFEST.MF) - This is not really a breaking change since org.eclipse.rse.core wouldn't have been of much use without SWT anyways. The denpendency is due to requeiring Display.asyncExec() for event notifications in SystemRegistry SystemPostableEventNotifier we should consider alternative ways for event notifications in a plain UI-less environment.
