Bug 4579 - Should we say anything about resolution of systemProperties value
Should we say anything about resolution of systemProperties value
Status: RESOLVED INVALID
Product: jbatch
Classification: Unclassified
Component: source
1
PC Windows
: P5 enhancement
: ---
Assigned To: cvignola
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-01-22 22:56 UTC by ScottKurz
Modified: 2013-02-04 22:14 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ScottKurz 2013-01-22 22:56:41 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.
Comment 1 cvignola 2013-01-23 18:52:46 UTC
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.
Comment 2 cvignola 2013-02-04 22:14:43 UTC
We are adding back restart parameters:  http://java.net/bugzilla/show_bug.cgi?id=4562 

So this bug is no longer vald.