Bug 4534

Summary: What is the purpose of the save-as attribute on a property?
Product: jbatch Reporter: mminella
Component: sourceAssignee: cvignola
Status: RESOLVED WORKSFORME    
Severity: normal CC: issues
Priority: P5    
Version: 1   
Target Milestone: ---   
Hardware: All   
OS: All   
Whiteboard:

Description mminella 2013-01-17 16:00:00 UTC
In each of the property configuration sections there is a new attribute, save-as.  Two questions here:
1.  Why is there a need for a secondary name when we already have a name?
2.  Is this to imply that properties configured with the save-as attribute will be persisted in some way from execution to execution?
Comment 1 cvignola 2013-01-17 16:56:04 UTC
More on saved batch properties is explained (perhaps not clearly) in section 5.9.  The reason for another name is because saved properties (which are persisted) are saved for the entire job. Properties can be defined on any artifact and the names are therefore non-unique.  Saved properties provides a way via substitution (#{saved[<property-name>]}) for property value from one step to be shared with another.
Comment 2 mminella 2013-01-17 20:19:33 UTC
With regards to section 5.9:
1.  Why isn't this behavior part of the job repository implementation?  I would expect parameters to be saved every time.  Now the question of what is used during the next execution is the next step.  I would expect that the user be required to re-pass in parameters every time the job is rerun.  If not, how do you remove a parameter on a subsequent run?
2.  Just to confirm, parameters are immutable through out a job execution, correct?
Comment 3 cvignola 2013-01-24 20:30:11 UTC
(In reply to comment #2)

1. These are not job parameters.  They are job properties.  The purpose is so that step2 can use a property value produced by step1 without having to write code in step1 to do it and without having the runtime automatically save every property to the repository. 

2. Parameters are immutable through out a job execution.



> With regards to section 5.9:
> 1.  Why isn't this behavior part of the job repository implementation?  I would
> expect parameters to be saved every time.  Now the question of what is used
> during the next execution is the next step.  I would expect that the user be
> required to re-pass in parameters every time the job is rerun.  If not, how do
> you remove a parameter on a subsequent run?
> 2.  Just to confirm, parameters are immutable through out a job execution,
> correct?