Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 247282

Summary: [remotecdt] Make remotecdt work over any subsystem that has service which can be adapted to IShellService
Product: [Tools] Target Management Reporter: Anna Dushistova <anna.dushistova>
Component: RSEAssignee: Anna Dushistova <anna.dushistova>
Status: RESOLVED FIXED QA Contact: Martin Oberhuber <mober.at+eclipse>
Severity: enhancement    
Priority: P3    
Version: 3.0.1   
Target Milestone: 3.1 M7   
Hardware: PC   
OS: Linux   
Whiteboard:
Bug Depends on: 267951    
Bug Blocks:    
Attachments:
Description Flags
patch that fixes the issue mober.at+eclipse: review-

Description Anna Dushistova CLA 2008-09-15 08:04:38 EDT 
Currently remotecdt works only with hosts that have shells subsystem, and doesn't work with those that have only terminals. It would be great if remotecdt could work over any subsystem that has suitable service.
Comment 1 Martin Oberhuber CLA 2008-09-15 08:37:13 EDT 
That should be very simple to do, like you already did for the Shell Processes Subsystem?
Comment 2 Anna Dushistova CLA 2008-09-16 04:50:57 EDT 
I guess so.
Comment 3 Anna Dushistova CLA 2008-09-17 18:15:27 EDT 
Created attachment 112839 [details]
patch that fixes the issue

I would like to remove RemoteRunLaunchDelegate.getConnectedRemoteService(),
since I replaced it with two methods: getConnectedFileRemoteService and getConnectedShellRemoteService. But getConnectedRemoteService() is public method.
What do you think?
Comment 4 Martin Oberhuber CLA 2008-09-30 08:37:37 EDT 
Comment on attachment 112839 [details]
patch that fixes the issue

Most of the patch looks good, but I see one big problem with the following: just opening the Remote Launch dialog will instantiate ALL subsystems, regardless if they are ever going to be needed or not.

We made big strides in 3.0 going towards lazy loading of only those subsystems that are actually needed. We should not throw this away again.

The problem, of course, is that we do not currently have any static markup in the plugin.xml that would tell us whether any given Subsystem actually has a Service that adapts to an IShellService.

I see two options for fixing this: (a) going towards "subsystem configuration families" (bug 217894) with static markup, or (b) being less strict when populating the host combo (i.e. allowing hosts in even if we are not sure that it will work eventually), and making the verification of a particular host only once it is selected by the user (i.e. show an error decorator "This host cannot be used for Launching" in case it is selected), such that only in case a host is selected, we need to instantiate its subsystems.
Comment 5 Anna Dushistova CLA 2009-04-22 17:07:49 EDT 
It was fixed along with bug 267951, I just added those hosts that have "terminals"  as subsystem category to the pulldown, so lazy activation should not be affected.

Not sure if we should reassign this bug to CDT now...