Bug 4715

Summary: Do we want to have restart parameters applied as overrides?
Product: jbatch Reporter: ScottKurz
Component: sourceAssignee: cvignola
Status: RESOLVED FIXED    
Severity: enhancement CC: issues, mminella
Priority: P5    
Version: 1   
Target Milestone: ---   
Hardware: PC   
OS: Windows   
Whiteboard:

Description ScottKurz 2013-02-23 16:21:30 UTC
See discussion about issue #1 in Bug 4702.  Restart properties were overrides way back (early draft timeframe) and RI/TCK still treats them as overrides.

Which do we want?
Comment 1 ScottKurz 2013-02-23 16:24:16 UTC
Note that in Bug 4702 Michael raised the question of how to "unset" a parameter on override. 

Should setting the Property value to 'null' be the answer?
Comment 2 cvignola 2013-02-28 17:41:30 UTC
In the Proposed Final Draft,  job parameters are not overrides.  Rather, they are available to a job level substitution pool.  Job Parameter values may be freely substituted into attribute values using 

#{JobOperator['job parameter name']}

See section 5.7 Job XML Substitution.

So for example,  a job developer would choose to allow a job parameter to set (or influence) the value of a property - e.g.

<property name="infile.name" value="#{jobParameters['infile.name']}?:in.txt;"/>

Missing from the section is treatment of restart behavior, which needs to state that job parameters from the original start are saved and used on restart.  New parameters may be specified on the JobOperator.restart() method and replace saved job parameters of the same name.  

Updated text will appear in PFD v1.5
Comment 3 mminella 2013-02-28 17:48:32 UTC
Chris,

How does that address the scenario of unsetting parameters?  Say I passed in a parameter on the first execution of the job, but on the restart I want to go back to the default.  What is the process for that?
Comment 4 ScottKurz 2013-02-28 17:55:10 UTC
(In reply to comment #3)
> Chris,
> How does that address the scenario of unsetting parameters?  Say I passed in a
> parameter on the first execution of the job, but on the restart I want to go
> back to the default.  What is the process for that?


I think we could start from the example currently at the end of Sec. 5.7:


•<property name="infile.name" value="#{jobParameter ['infile.name']}?:in.txt;" />

infile.name = value of infile.name job parameter or "in.txt" if infile.name job parameter is null.

------------------------------------------------------------------------------

First, since Properties can't hold 'null'... the "infile.name job parameter is null" condition would more precisely be:  "infile.name" is not present as a key in the "Properties" object.  

So Michael has a valid point... there's no way to unset it to 'null' at the moment.
Comment 5 cvignola 2013-02-28 18:58:00 UTC
(In reply to comment #4)

Scott,

Honestly, I've never considered "unset" an important use case.  I was really focused on common use cases and ease of use.  Typically, on restart, you only need to override one or two parameters, if any.  That's why I liked the idea of saving reusing, and optionally overriding the original start parameters.  But perhaps I'm getting too focused on how the APIs might be used in contrast to what the APIs themselves should do.  

So let's consider this:

1) Save job parameters per (re)start in JobExecution.  We already have JobOperator.getParameters(long executionId), so we are already headed in that direction. 

2) Remember NO parameters on restart. Use only the parameters specified on restart for #{JobParameter} substitutions on the new execution.  

If the user of JobOperator wants to reuse previously specified parameters, they can do so by retrieving those parameters from the appropriate JobExecution and passing in the ones they want on restart.  Of course, they could override or omit any of those parameters.  Moreover, they could specify different or additional parameters as well.

Thoughts?


> (In reply to comment #3)
> > Chris,
> > How does that address the scenario of unsetting parameters?  Say I passed in a
> > parameter on the first execution of the job, but on the restart I want to go
> > back to the default.  What is the process for that?
> I think we could start from the example currently at the end of Sec. 5.7:
> •<property name="infile.name" value="#{jobParameter ['infile.name']}?:in.txt;"
> />
> infile.name = value of infile.name job parameter or "in.txt" if infile.name job
> parameter is null.
> ------------------------------------------------------------------------------
> First, since Properties can't hold 'null'... the "infile.name job parameter is
> null" condition would more precisely be:  "infile.name" is not present as a key
> in the "Properties" object.  
> So Michael has a valid point... there's no way to unset it to 'null' at the
> moment.
Comment 6 mminella 2013-02-28 19:53:19 UTC
Chris,

What you suggest (remembering no parameters on restart) would be my vote.  It is actually the way we solved that issue when implementing non-identifying job parameters recently.