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

Bug 316565

Summary:

Failed to resolve the filter for a non-connected subsystem

Product:

[Tools] Target Management

Reporter:

Samuel Wu <samuelwu>

Component:

RSE

Assignee:

David McKnight <dmcknigh>

Status:

RESOLVED FIXED

QA Contact:

Martin Oberhuber <mober.at+eclipse>

Severity:

normal

Priority:

CC:

ankitp, dmcknigh, majmal

Version:

3.2

Target Milestone:

3.2.1

Hardware:

OS:

Windows XP

Whiteboard:

Attachments:

Description	Flags
patch to account for subsystems that don't support connect	none

Description Samuel Wu

2010-06-10 22:56:47 EDT

We have some subsystems which contain filters. These filters can be resolved without explicit connection. These filters work fine in RSE 3.0.3.x but fail to resolve in RSE 3.2. 
The method to resolve the filter is in SystemFetchOperation.execute(). A new check ensureConnected(ss,monitor) has been added and it returns an empty array when check fails. The old method tries to connect the subsystem but resolves the filter regardless of the connection result. 
Since we have some subsystems which don't require connection, they can be resolved in 3.0.3.x and fail to be resolved in 3.2.

Comment 1 David McKnight

2010-06-11 08:32:26 EDT

Is this reproducible using RSE?  If not, could you please provide example code to reproduce the problem?

Comment 2 Mohammed Ajmal

2010-06-11 11:20:14 EDT

Dave,

This problem will be reproducible with ANY subsystem that supports expandable filters but does NOT support connections using the latest RSE. I did a bit of investigation myself and here's what I've found:

In RSE 3.0.x branch, the execute() method of SystemFetchOperation attempts to connect to the subsystem on line 282:

ss.getConnectorService().connect(monitor);

Then, *whether this connect operation succeeds or not*, the execute() method carries on to try and resolve the filters (beginning on line 305 onwards).

Contrast this with the new behaviour in RSE head. Again, in the execute() method of SystemFetchOperation, we start resolving filter strings on line 362 with the following snippet:

		Object[] children = null;
		if (!isPromptable){
			if (!ensureConnected(ss, monitor)){
				children = new Object[0];
				_collector.add(children, monitor);
				return;
			}
		}

Connecting to the subsystem has been moved into the ensureConnected() method. But notice that now, if the connect doesn't succeed, we return immediately and *do not attempt to resolve filter strings*.

So, if my understanding is correct, the new behaviour enforces that the subsystem is connected before trying to resolve filter strings. This won't work for subsystems that don't support connections. I think the ensureConnected() requirement should only be enforced for subsystems that actually support connection (i.e. ss.getSubSystemConfiguration().supportsSubSystemConnect() is true). Otherwise, filter strings should be resolved with or without a connection.

Comment 3 David McKnight

2010-06-11 11:44:40 EDT

Created attachment 171739 [details]
patch to account for subsystems that don't support connect

Mohammed, thanks for the detailed explanation.  Could you see if this patch helps?

Comment 4 Mohammed Ajmal

2010-06-14 11:44:33 EDT

Dave, the patch works great. Thanks.

Comment 5 David McKnight

2010-06-23 10:17:18 EDT

I've committed the change to cvs.