Bugzilla – Bug 4579
Should we say anything about resolution of systemProperties value
Last modified: 2013-02-04 22:14:43 UTC
Though in bug 4350, we solved a related problem, we left unstated when exactly
a 'systemProperties' resolution happens in JSL substitution.
It would seem that there's room now for an implementation to offer a backdoor method for doing the equivalent of supplying restart parameters... that's simply because you could set a system property to one value initially and then to a later value before restart.
Did the move to disallow restart parameters intend to prevent this type of usage as well? If so, I think this should be stated...
Actually I'd go further and say the most obvious interpreation is that the systemProperties value should in fact be read anew with each restart. Would there be any objections say on having a TCK test depending on this behavior?
Looking at the same properties from another end of the spectrum... one could imagine implementation A doing a resolution at job start time, i.e. "upfront"... while implementation B defers resolution until that exact step is ready to execute. Does this ambiguity too need to be closed down?
I'm not as worried about this latter case... implementation B in this example is getting into complicated territory regarding the entirety of property substitution and inheritance... and getting into corner cases probably too complex to spend too much time worrying about. I was just mentioning this for completeness.
What additional we say about resolving property substitution from system properties must align with resolution of http://java.net/bugzilla/show_bug.cgi?id=4562
If Bug 4562 reinstates restart parameters, then I don't think anything special need be said concerning substitution from system properties.
If Bug 4562 reaffirms having NO restart parameters, then I think the spec needs to say that substitutions are not reprocessed on restart. I.e. the original post-substitution Job XML is what gets used on restart.
We are adding back restart parameters: http://java.net/bugzilla/show_bug.cgi?id=4562
So this bug is no longer vald.