Bug 4350 - Need any late-binding/late-resolution of JSL substitution properties
Need any late-binding/late-resolution of JSL substitution properties
Product: jbatch
Classification: Unclassified
Component: source
PC Windows
: P5 normal
: ---
Assigned To: cvignola
Depends on:
  Show dependency treegraph
Reported: 2012-11-20 16:04 UTC by ScottKurz
Modified: 2013-01-16 16:09 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description ScottKurz 2012-11-20 16:04:51 UTC
Seems like there might be some value in having a "late binding" type of property, to allow step1 to influence a property used for step 2.

Seems like the only type of substitution which would be a candidate for this type of thing is the system property.   The JSL properties and the job parameters are determined at job start/restart time.

(And I think it is an OK thing for any old API to set a System property, even in JEE, right?) 

Or maybe this makes property substitution too complicated and this type of dynamic binding should be done via JobContext.   The downside of that, of course, is that your app makes use of properties but with no integration into the view of property usage you get via the other JSL/substitution property mechanisms.
Comment 1 ScottKurz 2012-11-21 16:09:27 UTC
Incorporating Wayne's comment...something like this from SpringBatch would be a solution to my issue (but it's not in the public draft).

<property name="resource" value="#{jobExecutionContext['input.file.name']}" />

Maybe we should also still clarify when the system property substitution occurs...I'm thinking at job start time as the JSL is parsed upfront.
Comment 2 cvignola 2012-12-06 20:26:51 UTC
Well, the spec includes the #{jobProperty[]} substitution.  But what's missing for step N to influence step N+1 is a means to capture and expose output properties. 

To do that, we'd have to do like SpringBatch and persist a step's property values at end of step and expose them through something like #{jobExecution[]}. The output properties have to be persisted so they are available across restarts.

I think it is generally a useful idea, so I will add it to the spec. 

Since the runtime will persist the properties of all steps,  it makes sense to store them in the StepExecution.   

For a given step N+1 to substitute an output property from step N,  it must have a way to designate from which step to resolve the property.  So I propose something like:


Comment 3 cvignola 2012-12-20 15:55:55 UTC
Ok, so with no further discussion since my last comment, I will proceed to add this to the spec.
Comment 4 cvignola 2013-01-16 16:09:57 UTC
"saved" property was added to the spec to address this