Bugzilla – Full Text Bug Listing
| Summary: | TCFServiceManager.launchAgent(ITCFAgentLauncher) peer matching is inexact | ||
|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | John Cortell <john.cortell> |
| Component: | cdt-debug-edc | Assignee: | Ken Ryall <ken.ryall> |
| Status: | RESOLVED WONTFIX | QA Contact: | Ken Ryall <ken.ryall> |
| Severity: | normal | ||
| Priority: | P3 | ||
| Version: | 7.0 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
(this is part of a batch change) The Eclipse CDT EDC (https://wiki.eclipse.org/CDT/cdt-debug-edc) is now obsolete and has not had any active development since 2011. Therefore the still open bugs are being marked as wontfix. The git repo for the project still exists for posterity at https://git.eclipse.org/c/cdt/org.eclipse.cdt.edc.git/ |
AbstractFinalLaunchSequence derivates specifies a minimum set of TCF peer attributes to indicate what agent the launch should use. The launch sequence respects the entire set when looking through the already discovered peers[1], and for determining what agent-launcher to use otherwise[2]. But after asking the agent-launcher to do its thing, it tries to match newly discovered peers based only on the user-friendly peer name (IPeer.ATTR_NAME). In other words, public void peerAdded(IPeer peer) { if (peer.getName().equals(descriptor.getPeerName())) { waitForPeer.setData(peer); } } is inadequate. For starters, whose to say if the AbstractFinalLaunchSequence derivative even specified IPeer.ATTR_NAME as a qualifying attribute? And even if it did, how about all the other attributes it may have specified? [1] See the call to tcfServiceManager.getRunningPeers() in AbstractFinalLaunchSequence.findPeer(RequestMonitor) [2] See the call to tcfServiceManager.getRegisteredAgents() in AbstractFinalLaunchSequence.findPeer(RequestMonitor)