Bugzilla – Full Text Bug Listing
| Summary: | RM does not show up in RM view when added to service configuration | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Tools] PTP | Reporter: | Greg Watson <g.watson> | ||||
| Component: | RM | Assignee: | Greg Watson <g.watson> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | arossi | ||||
| Version: | 4.0 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | Macintosh | ||||||
| OS: | Mac OS X | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Greg Watson
Greg, I've never seen this work correctly. I'm not sure what I may have done to change this behavior from what it was, according to your recollection ... but I will look at it. Note: all I did to this area of the code was to add that iterated search for the Rm in all the service configurations in the call to remove a RM; I don't believe I touched anything else ... It may have been broken before your changes. But I thought it was working... It should be handled by a SERVICE_CONFIGURATION_CHANGED or SERVICE_PROVIDER_CHANGED (can't remember which) in ModelManager. It's the former. I think it's not handling adding a provider the to configuration for the first time (when oldProvier == null) Greg, I diff'd my current ModelManager against 1.152 (12/02/09 2:15), and it shows no structural changes. I note that I fooled around a bit with adding code on 6/4/2010, but it looks like I restored the ModelManager to what it was before then ... I'll look at the handler condition you mentioned. Why does the check for an oldProvider need to be made here?
if (oldProvider != null && oldProvider instanceof IResourceManagerConfiguration) {
IServiceProvider newProvider = config.getServiceProvider(fLaunchService);
if (newProvider != null && newProvider instanceof IResourceManagerConfiguration) {
IResourceManagerControl rm = (IResourceManagerControl)getResourceManagerFromUniqueName(((IResourceManagerConfiguration)oldProvider).getUniqueName());
if (rm != null) { rm.setConfiguration((IResourceManagerConfiguration)newProvider);
}
}
}
OK, just to preserve the old unique name mapping ... This code is broken. It looks like: 1. An RM only exists if it's part of a service configuration. 2. Adding an RM to an existing configuration with no RM does nothing. 3. Adding an RM to an existing configuration containing an RM replaces the configuration of the existing RM (does that make sense?) I'm testing code to fix 2 now. Not sure about 3, but will leave for now. Yes, this code is hardly clear to me. My question to you before the last post was: where do I find the RM if there is no service configuration? Which basically your point 1. states as well. Created attachment 171427 [details]
proposed patch
Please test the attached patch. You should update org.eclipse.ptp.core before applying as I reformatted the files so you could see more clearly what has changed. I found another bug where if you replaced an RM in an existing configuration it wasn't updated. This was because the default equals() for ServiceProvider only checks the descriptor ID. Since both RM's use the same ServiceProviderDescriptor, they were always comparing equal. I've added an equal() to the RM service provider that compares the unique ID instead. The original problem seems to be fixed; however, just by way of a note: 1. The Service Configuration view still does not refresh correctly when RMs are added or removed. 2. There is still no way to add an RM to more than one configuration through the Resource Managers view. Committed. #2 should probably have a bug. |