Bug 174495 - [components][api] two or more subsystems of the same kind cannot be added to the same host
Summary: [components][api] two or more subsystems of the same kind cannot be added to ...
Status: ASSIGNED
Alias: None
Product: Target Management
Classification: Tools
Component: RSE (show other bugs)
Version: 2.0   Edit
Hardware: PC Windows 2000
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: dsdp.tm.rse-inbox CLA
QA Contact: Martin Oberhuber CLA
URL:
Whiteboard:
Keywords: api, investigate
Depends on:
Blocks:
 
Reported: 2007-02-16 14:48 EST by Javier Montalvo Orús CLA
Modified: 2008-10-07 04:44 EDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Javier Montalvo Orús CLA 2007-02-16 14:48:23 EST
When creating a host containing two servers of the same kind, only one is shown in the Remote Systems. Note that if more than 2 are added, the subsystems shown are the expected - 1. After restarting RSE, only 1 subsystem is shown.

A test code to reproduce the issue could be:

IHost conn = registry.createHost("Discovery", "name", "name", "description"); 
SystemRegistry registry = RSEUIPlugin.getDefault().getSystemRegistry();
ISubSystemConfiguration sub1 = registry.getSubSystemConfiguration("ftp.files"); 
ISubSystemConfiguration sub2 = registry.getSubSystemConfiguration("ftp.files");
registry.createSubSystems(conn, new ISubSystemConfiguration[]{sub1,sub2});

It is necessary to support more than one server of the same kind, as one target can present more than one server (in different ports) such as FTP or telnet servers.
Comment 1 Martin Oberhuber CLA 2007-03-20 14:28:49 EDT
There are some issues with having multiple subsystems of the same kind. Below is a capture of the discussion we had on http://wiki.eclipse.org/index.php?title=DSDP/TM/Committer_Phone_Meeting_20-Mar-2007

#  DaveM: wants to switch service for a given subsystem after created. Wants to share "File" filters between services. Wants to share user actions between multiple shells; Uwe: will need to change context menu actions;
# DaveM: What file subsystem to link with the editor?
# DaveM: Refresh events - when a new file is created under a folder, all file subsystems should be refreshed -- multiple queries to subsystems; Martin -- we can do it today (and discovered issues when doing so), the only difference is that they are under different Host nodes
# DaveM: Save in editor - which file subsystem do we use to upload? - first available or the one we opened with - path in the cache is the same! Right now, we keep track of the connection we used when opening the file (Martin: in the future, keep track of the subsystem) 

Summing up, it seems like 
1. Once instanciated, should it be possible to change the service of a given
   subsystem at runtime? What if multiple subsystems with the same service
   result from this? - Martin thinks that changing the service at runtime
   is not a good idea. DaveM wants to have it changeable (what's the use
   case behind changing?)
2. What about filters - should they be the same for multiple subsystems of the
   same kind? Martin thinks no; DaveM thinks it is a bug if a filter
   created for FTP is not available after switching to dstore or ssh.
3. User actions created for shell service A should also be available for shell
   service B.
4. Current implementations which just take "the first IRemoteFileSubSystem"
   should be changed to take "the first connected" one
5. There might be a need to get subsystems sorted in a user-defined manner
   to clarify which one is the first
6. Same file accessed through multiple different channels can lead to caching
   and refresh issues - but we also have these right now when the same file
   is accessed through multiple channels below multiple host definitions.
7. Loading editor through subsystem A needs to also store it through the
   same subsystem - editor needs to remember
8. There might be menu enablement issues
Comment 2 Martin Oberhuber CLA 2007-05-09 10:41:02 EDT
Adding more subsystems of the same kind is interesting but also not easy to handle. It could be especially interesting with a polished wizard as requested by bug #176490. Deferring for now, to look at it again later.