In-memory repository and ExecutionContext

[smichels]

Hello,

We are trying to pass some simple parameters from one Job to another. Code looks like this:
ctx.putLong(CLAIM_ID, currentClaim.getId());
System.out.println("Claim id in exn ctx "+se.getExecutionContext().getLong(CLAIM_ID));
se.setExecutionContext(ctx);

In the following step we access the ExecutionContext like this:
ExecutionContext cxt = se.getExecutionContext();
System.out.println("Claim id: "+ cxt.getLong(CLAIM_ID));

Resulting in this error:
INFO: Job: [SimpleJob: [name=simpleJob]] failed with the following parameters: [{}{timeOfKickoff=1208842406699}{}{}]
java.lang.ClassCastException: Value for key=[claimId] is not of type: [class java.lang.Long], it is [null]

We are using an In-Memory Job Repository and, as you can tell from the exception, a SimpleJob.
Does and ExecutionContext not get passed between steps when using an in-memory repo?
Any clues appreciated.

Thanks, Sjoerd

[Dave Syer]

An ExecutionContext is scoped to the step, so it doesn't get passed between steps (independent of the repository implementation). To use it like this to pass information between steps you need to write a StepExecutionListener that listens to both steps and has instance variables that are used to transfer data between one step and the next.

[smichels]

Hi Dave,

Thanks for the fast reply. You state that an ExecutionContext is scoped to a Step. However, the Spring Batch reference guide states:
"An ExecutionContext represents a collection of key/value pairs that are persisted and controlled by the framework in order to allow developers a place to store persistent state that is scoped to a JobInstance."

Is there any other mechanism offered by Spring Batch for passing data between different steps in a job?

Thanks again,
- Sjoerd

[Dave Syer]

Sorry, the user guide is wrong (I have changed it for the next release). So...

you need to write a StepExecutionListener that listens to both steps and has instance variables that are used to transfer data between one step and the next.

This is sort of a workaround for 1.0. You might find something scoped at the JobExecution level in future versions (there are a couple of JIRAs already: http://jira.springframework.org/browse/BATCH-264, http://jira.springframework.org/browse/BATCH-505).

[smichels]

The JIRA's describe our use case exactly.
For now we have created our own container that we inject into the steps.