scottkurz
commented
2 years ago Seems we're not going to get to this in 2.1.
Open follis opened 4 years ago
scottkurz
commented
2 years ago Seems we're not going to get to this in 2.1.
Originally opened as bug 7475 by ScottKurz
--------------Original Comment History---------------------------- Comment from = ScottKurz on 2016-01-11 17:23:38 +0000
See for example the discussion in: https://java.net/projects/jbatch/lists/public/archive/2015-12/message/2
Comment from = cf126330 on 2016-01-12 03:54:09 +0000
Continue the discussion from mailing list, one potential drawback with Dmitry's approach (adding property to batch.xml) is users will have to deal with 2 separate xml files (job.xml and batch.xml) to get all properties, and this is not very user-friendly.
A property, when defined as a sub-element of a batch artifact, people would naturally think it is scoped within that parent element, though it can also be extended to support some sort of exporting semantics. But to which part of the job is the exported property visible? Is the exported property visible to the subsequent step, all following steps? Is it visible to the immediate enclosing component, or all enclosing components (e.g., a item reader inside a step inside a flow inside a split...)
Adding a new place like #{jobContext['step2.fileName']} seems a better fit but also has its own complications. we need to be careful not to confuse users with the current javax.batch.runtime.context.JobContext#getProperties.
It also implies jobContext will have an additional data container besides job transient user data, which essentially has the same purpose as the existing transient data. Or we could re-use the current job transient user data, like
{jobTransientData['fileName']}, to refer to a fileName property of the data bean, or a fileName key of the map-type value. Since it's transient user data, it implies the data is mutable and exported to the entire job.
Ideally, I would avoid adding a new place like jobContext just for the purpose that is already fulfilled by current design.
Comment from = ScottKurz on 2016-01-12 17:10:22 +0000
Cheng,
Agree batch.xml is the wrong place to expand into.
Agree that we should start with a job-level scope rather than defining the syntax for substituting an output or inout property at a more granular scope.
So yes, this is steering us to an additional function on JobContext, potentially creating the dilemma "do I put this in transient data or these new output properties?" (not to mention, like you noted, it's a bit surprising when you learn that JobContext#getProperties supplies only the non-writable children of the job-level properties.)
One more note: given that JobContext is "thread-local" (in the parallel batch sense), setting transient data on the partitions and split-flow JobContexts don't propagate up. This too could be a burden placed on the application to deal with if necessary, like it is for transient data.
I still think this is useful enough that all of those issues are worth considering and overcoming.
If the property value were always coming from app code it's a stronger case that the 1.0 function is enough and do it yourself.
But the ability to supply defaults and overrides seems compelling to me..
E.g. calculate file from step 2 with job parm override:
Maybe we can think up decent names to go along with this?