8

In the Spring Batch step-scope documentation, there are three unexplained spring-batch context maps: jobParameters, jobExecutionContext, and stepExecutionContext.

Springsource sample code, combined:

<bean id="flatFileItemReader" scope="step"
  class="org.springframework.batch.item.file.FlatFileItemReader">
    <property name="var1" value="#{jobParameters['input.file.name']}" />
    <property name="var2" value="#{jobExecutionContext['input.file.name']}" />
    <property name="var3" value="#{stepExecutionContext['input.file.name']}" />
</bean>

What are the default parameters available within jobParameters, jobExecutionContext, and stepExecutionContext?

There are also likely differences between what's available in Spring Batch version 1.x vs. 2.x vs. 3.x--the documentation is pretty scarce in this area.

JJ Zabkar
  • 3,792
  • 7
  • 45
  • 65

3 Answers3

5

There aren't any default values. Think of jobParameters, jobExecutionContext, and stepExecutionContext as glorified Maps with helper methods for different primitive data types, e.g. getInt(). They're typically accessed from the StepExecution and JobExecution objects passed to *ExecutionListeners, or injecting using value injection, e.g. @Value("#{jobParameters['foo']}").

In this case, input.file.name is just a name chosen by the developer, e.g. maybe corresponding to a command line job parameter specified to the CommandLineJobRunner.

Emerson Farrugia
  • 11,153
  • 5
  • 43
  • 51
  • Just to clarify: in order add custom variables to my `StepExecution` within the `step` scope, I extended `StepExecution` and instantiated `MyStepExecution` during the Spring Batch partitioning phase. The job-level parameters ended up being not needed. – JJ Zabkar Mar 18 '14 at 15:30
  • So adding your custom variables to `StepExecution.getExecutionContext()` didn't work? It's the usual way to do it. The accepted answer to this question shows an example: http://stackoverflow.com/questions/18830994/spring-batch-late-binding-for-stepexecutioncontext-not-working – Emerson Farrugia Mar 18 '14 at 16:44
  • Yes, that did work, but I didn't like the testability of it--seemed like too much `String` fudging; less semantic. I liked the declarative getters. – JJ Zabkar Mar 18 '14 at 19:37
  • Ah, OK. The reason for those particular data types is that they are straightforward to persist in the SERIALIZED_CONTEXT clob of the BATCH_STEP_EXECUTION_CONTEXT table in the Spring Batch RDBMS schema. (http://docs.spring.io/spring-batch/reference/html/metaDataSchema.html) Be careful that your customisations don't get lost on resuming failed jobs. – Emerson Farrugia Mar 18 '14 at 22:25
3

#{jobParameters}, #{jobExecutionContext} and #{stepExecutionContext} are the spEL (Spring Expression Language) counterpart of JobParameters, JobExecution and StepExecution objects available in late-binding to allow non-static access to this objects values from step scoped object.

They support access as Maps so you can access the ExecutionContext associated to JobExecution and StepExecution and values stored in JobParameters.

Also check StepScope documentation for more information.

Luca Basso Ricci
  • 17,829
  • 2
  • 47
  • 69
0

See the documentation

JobParameters are parameters passed in when starting the job

The execution contexts are for your use to store whatever you want. Typically, the step execution context will contain information to allow the step to restart (for restartable jobs).

Elements in the step execution context can be promoted to the job execution context if you want to communicate information between steps.

Gary Russell
  • 166,535
  • 14
  • 146
  • 179