Bugzilla – Full Text Bug Listing
| Summary: | allow for dynamically resolvable property values | ||
|---|---|---|---|
| Product: | [Tools] PTP | Reporter: | Albert L. Rossi <arossi> |
| Component: | RM | Assignee: | Albert L. Rossi <arossi> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | g.watson |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
I'm working on this and believe I can wrap it into the release. Half of it already is working. I'm pretty sure I can finish this today. The just-in-time resolution is not really a problem, as the value that is exposed in the widget goes directly into the configuration. This has been achieved as follows.
1. There is a point in the processing of <dynamic-value> where it is possible that String.replaceAll(tag, with) substitutes a 'with' which contains special characters (viz. '$'), which Java does not like because it also treats the 'with' as a regex. I substituted a custom method for replaceAll at that point in the code.
2. The JAXB RM needed to add one more preset value to the environment: control.working.dir. This will correspond to the dir on the remote host where PBS defaults the stdout and stderr files to.
3. For the stdout/stderr paths which are needed by the client, the PBS definition can now safely set the default value to ${ptp_rm:control.working.dir#value}/${ptp_rm:Job_Name#value}.o@jobId and ${ptp_rm:control.working.dir#value}/${ptp_rm:Job_Name#value}.e@jobId.
4. I added support in the PropertyType and AttributeType for "link-update-to". This is a function from the linked-end to the property or attribute where it appears (which can have many such links). This is because the push model was easier to implement. What this means is that when this property is updated, it propagates the update to the other properties or attributes named by the links such that the latter values are overwritten by this one. If the update is to an empty string, the default values are restored on the links.
I added this so that we can link the PBS Output_Path and Error_Path to the PTP client's ad hoc variables for these paths. E.g.,
<property name="stdout_remote_path" visible="true">
<default>${ptp_rm:control.working.dir#value}/${ptp_rm:Job_Name#value}.o@jobId</default></property>
...
<attribute name="Output_Path" type="string">
...
<link-update-to>stdout_remote_path</link-update-to>
</attribute>
The default value will automatically be overwritten if the use updates Output_Path; of course, the stdout_path can be changed without affecting the Output_Path (it's a one-way function), but the batch system doesn't have anything to do with that property, so the file still ends up either in the default location or the one set by Output_Path (I believe similar properties exist on LL and LSF).
Note: There is a way of keying the Output_Property to the JobId and JobName in the PBS batch file (I forget how this is done). If this is used, the user will have to substitute into stdout_remote_path the corresponding variable names that are understood by the JAXB RM, since the PBS-specific way of doing this (which is different for other batch systems) is unknown to PTP-JAXB. To make this fully automatic, we would need to add to the configuration a "property translator" and use it in the variable resolver (I might get around to looking at this).
5. There was also a small bug I noticed in the Table/Tree attribute viewer having to do with the display of default values for unchecked rows when the filter for displaying only checked boxes is removed (by checking the checkbox above the table). It turns out that refresh was not being called after the filter change. That has been fixed.
I'll close this bug after a bit more testing.
Done. |
This feature is necessary in order to support the automatic setting of stdout and stderr file paths based on batch-specific settings (such as with PBS). Implementation notes: We do not want to resolve the value in the environment map; that would make it like a constant (once resolved, it would remain unchanged). The unresolved string should actually appear to the user in the widget text areas, and only be resolved when the script is generated or the job launched. If the resolution takes place when the map values are written to the configuration, the configuration would then no longer contain the variable either, and this would interfere with the restoration of values from the current config. Thus the resolution must be just-in-time -- only when the script is produced or the properties are sent off during launch. This means we need to guarantee that commands are also resolved just-in-time. Finally, if we are allowing the present of variable tags (${...}) inside the widget text, then provision must be made whenever we do any replacement on these values (there are a few places in the code where this happens), because java.regex.Pattern does not like this when it is the value of the replacement. Something like escaping and then unescaping will need to take place in those cases. ALR