Bug 196838 - Deleted "Local" host re-appears after restart
Summary: Deleted "Local" host re-appears after restart
Status: RESOLVED FIXED
Alias: None
Product: Target Management
Classification: Tools
Component: RSE (show other bugs)
Version: 2.0   Edit
Hardware: PC Windows XP
: P3 minor (vote)
Target Milestone: 2.0.1   Edit
Assignee: David McKnight CLA
QA Contact: Martin Oberhuber CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 193323
  Show dependency tree
 
Reported: 2007-07-17 12:39 EDT by Martin Oberhuber CLA
Modified: 2007-07-19 12:51 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Oberhuber CLA 2007-07-17 12:39:01 EDT
CQ:WIND00098772

When deleting the "Local" host and quitting RSE,
it reappears after restarting.

We should assume that deleting a host is on purpose,
so we should not recreate it automatically on startup.

Some discussion about deleting "Local" hosts has been
done in bug #186880.

Perhaps we'd need some kind of flag file in the Workspace
to know whether Local has been auto-created already or not,
so we can avoid auto-creating it again after startup if
it has been deleted on purpose.

-----------Enter bugs above this line-----------
TM 2.0
installation : eclipse-SDK-3.3 (I20070625-1500), cdt-4.0.0, emf-2.3.0
RSE install  : workspace HEAD
java.runtime : Sun 1.6.0_01-b06
os.name:     : Windows XP 5.1, Service Pack 1
------------------------------------------------
systemtype   : Windows-local, Dstore-win, Dstore-linux
targetos     : Red Hat Enterprise Linux WS release 4 (Nahant Update 3)
targetuname  : Linux parser 2.6.9-34.EL #1 i686 athlon i386 GNU/Linux
targetvm     : Sun Java HotSpot(TM) Client VM (build 1.4.2_12-b03, mixed mode)
------------------------------------------------
Comment 1 Kevin Doyle CLA 2007-07-17 14:55:38 EDT
This is similar to bug #193323.  It doesn't matter if you delete or rename Local, a "Local" connection is always created.
Comment 2 David McKnight CLA 2007-07-17 15:56:29 EDT
In the RSE startup code we have this:

// new support to allow products to not pre-create a local connection
//	if (SystemResourceManager.isFirstTime() && SystemPreferencesManager.getShowLocalConnection()) {
if (SystemPreferencesManager.getShowLocalConnection()) {
	// create the connection only if the local system type is enabled
	IRSESystemType systemType = RSECorePlugin.getTheCoreRegistry().getSystemTypeById(IRSESystemType.SYSTEMTYPE_LOCAL_ID);
	if (systemType != null) {
		RSESystemTypeAdapter adapter = (RSESystemTypeAdapter)(systemType.getAdapter(RSESystemTypeAdapter.class));
		if (adapter != null && adapter.isEnabled(systemType)) {
			ISystemProfileManager profileManager = SystemProfileManager.getDefault();
			ISystemProfile profile = profileManager.getDefaultPrivateSystemProfile();
			String userName = System.getProperty("user.name"); //$NON-NLS-1$
			registry.createLocalHost(profile, SystemResources.TERM_LOCAL, userName);
		}
	}
}

The commented out line should fix this problem, although we don't have SystemResourceManager.isFirstTime() anymore.  
Comment 3 Martin Oberhuber CLA 2007-07-18 09:04:23 EDT
I think that SystemResourceManager.isFirstTime() is not quite sufficient.

Because it could be that at the first time RSE is run, the Local Feature is not yet installed so Local node would not be created at that time. If somebody installs the Local feature through update manager at a later time, now the node should be created.

Ideally, all the auto-creation stuff for the Local connection should be inside the local subsystem plugin; but this seems too much of a change for 2.0.1. What we can do is this:

Prefrences prefs = RSEUIPlugin.getDefault().getPluginPreferences();
String key = "localConnectionCreated.mark"; //$NON-NLS-1$
if (!prefs.getBoolean(key)) {
   if (otherChecksOK) {
       doCreateLocal();
       prefs.setBoolean(key, true);
   }
}
Comment 4 David McKnight CLA 2007-07-18 10:07:40 EDT
I've applied Martin's suggestion - i.e. using the preference.
Comment 5 David Dykstal CLA 2007-07-18 10:31:21 EDT
Dave --

One problem with using a preference to mark the initial creation of Local is that preferences can be exported to another workspace. I thought of this after my conversation with you. We should probably have an internal class - say RSEWorkspaceState - with a static method that contains this property and allocate the property as a file in the state location of the core plugin.
Comment 6 Martin Oberhuber CLA 2007-07-18 10:37:59 EDT
Dave, why do you think a separate class is needed for this? You can do e.g.

IPath statePath = RSECorePlugin.getDefault().getStateLocation();
IPath markPath = statePath.append("localHostCreated.mark");
File markFile = new File(marPath.toOSString());
if (!markFile.exists()) {
   //check prerequisites and doIt
   try { markFile.createNewFile(); } catch(Exception e);
}


BTW, I'd appreciate if you also removed the commented-out old code, I really see no reason for keeping this in there.
Comment 7 David Dykstal CLA 2007-07-18 10:58:36 EDT
Martin --

Yes, you can do this. I was concerned about tracking who is creating stuff in the state location. I thought a class would be the best way to centralize this, but its probably better and easier to just look for references to getStateLocation().

-- Dave
Comment 8 David McKnight CLA 2007-07-18 11:55:01 EDT
(In reply to comment #6)
> 
> BTW, I'd appreciate if you also removed the commented-out old code, I really
> see no reason for keeping this in there.
> 
I've removed the commented out code.

Comment 9 Martin Oberhuber CLA 2007-07-19 07:07:41 EDT
The current fix introduced an API regression since it no longer checks for
    SystemPreferencesManager.getShowLocalConnection()

This means that products can no longer switch off the auto-creation of Local by setting "rse.showLocalConnection=false" in plugin_customization.ini.

Also the fix should not use the Preferences as outlined in comment #6.
Reopening.
Comment 10 David McKnight CLA 2007-07-19 12:51:02 EDT
I've amended the code to honor SystemPreferencesManager.getShowLocalConnection() and I've changed the check to use a state file rather than a preference as suggested.