Bugzilla – Full Text Bug Listing
| Summary: | [JAXB] Resource manager fails to start after PTP upgrade | ||
|---|---|---|---|
| Product: | [Tools] PTP | Reporter: | Greg Watson <g.watson> |
| Component: | RM | Assignee: | Project Inbox <ptp-inbox> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | arossi |
| Version: | 5.0 | ||
| Target Milestone: | --- | ||
| Hardware: | Macintosh | ||
| OS: | Mac OS X | ||
| Whiteboard: | |||
|
Description
Greg Watson
Does this mean that the RM names now have to be unique? I think the configuration file names will need to be unique, yes. I presume you're checking if the file exists each time the RM is started? Otherwise I could remove the config file from my workspace, e.g. So Greg, if we don't use the URL of the resource, how are we going to load the configurations? So Greg, if we don't use the URL of the resource, how are we going to load the configurations? There are actually two issues here.
1. Loading. This occurs during the display. The lists are compiled dynamically from the plugin URLs and the workspace project. The URL is then stored in the configuration when the RM is chosen.
2. Building: If the in-memory data tree is not constructed for the current configuration, unmarshal is called, which validates the xml first. It the validation fails, an exception is thrown.
public static void validate(URL instance) throws SAXException,
IOException, URISyntaxException {
Source source = new StreamSource(instance.openStream());
try {
getValidator().validate(source);
} catch (SAXParseException sax) {
JAXBCorePlugin.log(printInfo(sax));
throw sax;
}
}
How do you think this should go if this behavior is not correct? Remember we need to unmarshal from a URL, because the config may be from a plugin or a file in the workspace.
Maybe the solution for now is to change the message to something like: "The configuration file for this resource manager is no longer available. This may be because the plugin was updated or the file was removed from the workspace. Please remove this resource manager and create a new one with a valid configuration file." In the future, it might be necessary to copy the configuration files to a well known location or provide some other mechanism for automatically updating the configuration file. OK, I think I see what you have in mind. We need a configuration cache in the platform area which users are not going to alter unless they want to be purposely malicious. When you bring up the RM Selection Wizard, the cache is updated with the configurations from plugins and workspace, but we don't delete from it (but we should probably provide an action to clear the cache). If the user eliminates from the workspace, it will not show up in the choices for a new RM, but the config will remain in the cache in case a current RM is still using it. If the plugin URL changes, the config will be rewritten to the cache, and since the actual config name will not have changed, any RM using it will still see it. Let me see what it will take to make these changes. If we can do it without breaking the API, I'll try to get it done (after I finish the XSD changes I'm working on now ...) Al Here's another thought. What if we immediately read the URL and store the serialized configuration inside the ResourceManager configuration instead of the URL? Sounds a lot simpler! (In reply to comment #9) > Sounds a lot simpler! OK, but three things. 1. This would entail changing the interface to the IJAXBResourceManagerConfiguration and associated utils. This is in jaxb.core, so it is not public (the downstream visibility is limited). I assume this is OK. 2. This is wasteful of memory, since the in-memory copy of the RM now will contain a copy of the serialized config instead of a pointer to the resource. But I don't imagine this is really an issue given the normal number of RMs and the contained size of the config (PBS generic for instance is 36K). 3. I have to make sure that embedding XML inside the RM config works. Have we done this elsewhere? Note that this is also a question in terms of my scheme for storing JobStatus in the monitor configuration. (In reply to comment #10) > (In reply to comment #9) > > Sounds a lot simpler! > > OK, but three things. > > 1. This would entail changing the interface to the > IJAXBResourceManagerConfiguration and associated utils. This is in jaxb.core, > so it is not public (the downstream visibility is limited). I assume this is > OK. > > 2. This is wasteful of memory, since the in-memory copy of the RM now will > contain a copy of the serialized config instead of a pointer to the resource. > But I don't imagine this is really an issue given the normal number of RMs and > the contained size of the config (PBS generic for instance is 36K). > > 3. I have to make sure that embedding XML inside the RM config works. Have we > done this elsewhere? Note that this is also a question in terms of my scheme > for storing JobStatus in the monitor configuration. Agh. I just realized this is going to add another complication. Once we store it in the RM config, it will be the same for the life of the RM. So if you change a custom XML file in the workspace, an already existing RM will not pick up the change? Do you think goes against user expectations? If so, then I think we should abandon this approach. (In reply to comment #11) > (In reply to comment #10) > > (In reply to comment #9) > > > Sounds a lot simpler! > > > > OK, but three things. > > > > 1. This would entail changing the interface to the > > IJAXBResourceManagerConfiguration and associated utils. This is in jaxb.core, > > so it is not public (the downstream visibility is limited). I assume this is > > OK. > > > > 2. This is wasteful of memory, since the in-memory copy of the RM now will > > contain a copy of the serialized config instead of a pointer to the resource. > > But I don't imagine this is really an issue given the normal number of RMs and > > the contained size of the config (PBS generic for instance is 36K). > > > > 3. I have to make sure that embedding XML inside the RM config works. Have we > > done this elsewhere? Note that this is also a question in terms of my scheme > > for storing JobStatus in the monitor configuration. > > Agh. I just realized this is going to add another complication. Once we store > it in the RM config, it will be the same for the life of the RM. So if you > change a custom XML file in the workspace, an already existing RM will not pick > up the change? Do you think goes against user expectations? If so, then I > think we should abandon this approach. Actually, come to think of it, this will also be true in the cached case, because the cache is only updated (as per my proposal) only when the selection wizard is called. This will create unexpected behavior, because if the user does not call the wizard but makes a change, the change won't be reflected; whereas, one the wizard has been called after the change, the old RM (the next time it is booted) will reflect the change. That's not good. I'm not sure, however, at what point we need to synchronize the cache. Perhaps this needs to be done when the Parallel Runtime Perspective or Parallel Debug Perspective is opened. Can that be done? (In reply to comment #11) > (In reply to comment #10) > > (In reply to comment #9) > > > Sounds a lot simpler! > > > > OK, but three things. > > > > 1. This would entail changing the interface to the > > IJAXBResourceManagerConfiguration and associated utils. This is in jaxb.core, > > so it is not public (the downstream visibility is limited). I assume this is > > OK. Yes that's ok. > > > > 2. This is wasteful of memory, since the in-memory copy of the RM now will > > contain a copy of the serialized config instead of a pointer to the resource. > > But I don't imagine this is really an issue given the normal number of RMs and > > the contained size of the config (PBS generic for instance is 36K). I don't think that's a big issue. > > > > 3. I have to make sure that embedding XML inside the RM config works. Have > we > > done this elsewhere? Note that this is also a question in terms of my scheme > > for storing JobStatus in the monitor configuration. Can't this just be a string? > > Agh. I just realized this is going to add another complication. Once we store > it in the RM config, it will be the same for the life of the RM. So if you > change a custom XML file in the workspace, an already existing RM will not pick > up the change? Do you think goes against user expectations? If so, then I > think we should abandon this approach. I don't think this is an issue. I consider the XML files to be resource manager *definitions* rather than configurations. The configuration is what is stored when the resource manager is configured. If the definition subsequently changes, I don't think it's necessary to update the confituration. OK, then. A resource manager's configuration is what it is for its lifetime. The unknown (I've yet to try it) is embedding XML inside XML (isn't that how the RM Configuration is represented in a file?). If strings are saved as CDATA, that should work. If they're not, then strange things could happen. But I will go ahead and try out the idea of storing the config inside the config, so to speak. The changes have been made. I did not alter the RMConfiguration API method setConfigurationName(...) even though it now does not set just the name, but the entire configuration for JAXB RMs. I've tested by instantiating from the workspace and then removing the file (through a backdoor, no less). Please verify and I will close the bug. I've been trying to test this, but it requires two builds of PTP and now the update sites appear to be down... :-( I can verify this is working now. |