Missing note about not scoping Step beans with Job scope #3900
Comments
kzander91
added
status: waiting-for-triage
fmbenhassine
added
has: minimal-example
|
Thank you for opening this issue and for providing a minimal example. The problem here is the scoped step. A step should not be scoped (with step scope or job scope). what should be scoped instead is the component of the step (tasklet, reader, writer, etc). In your case, it is the item processor that should be scoped to use late-binding, not the step itself. Here is an example of how your sample should be changed: @Bean
Job job() {
return jobs.get("job") //
.start(step()) //
.build();
}
@Bean
Step step() {
return steps.get("step") //
.<String, String>chunk(1) //
.reader(() -> String.valueOf(Math.random())) //
.processor(itemProcessor(null)) //
.writer(new ListItemWriter<>()) //
.build();
}
@Bean
@StepScope
public ItemProcessor<String, String> itemProcessor(@Value("#{jobParameters['param']}") String param ) {
return item -> {
log.info("Processing item: '{}' Param: '{}'", item, param);
TimeUnit.SECONDS.sleep(1L);
return item;
};
}With those changes, the sample works as expected. There is a mention about not scoping I will change this into a documentation issue and update the docs accordingly. |
fmbenhassine
added
in: documentation
and removed
in: core
status: waiting-for-triage
fmbenhassine
changed the title
|
Hi @fmbenhassine , if steps should have scope step or job, how can i dynamically set the chunkSize from a job parameter? edit: Is this a good solution? |
Done: 7481cf8 @marbon87 I don't know how I missed your message, apologies. Indeed, I talked about job-scoped steps in that answer on stackoverflow, but it seems like I should have elaborated more on the available options and, more importantly what is recommended and what is not. I updated that answer with more details: https://stackoverflow.com/a/67365622/5019386
Yes, just like the item reader or writer, the completion policy is the component to scope instead of the step itself. The docs were updated accordingly. I mentioned the fact that a step should not be scoped on SO, but I will iterate it here: while technically possible, a step should not be scoped. The reason is simple: scoping a step does not make sense, in fact it means: do not create that step definition until this step is started at runtime, but to start that step at runtime it needs to be defined upfront.. While one might think that the the step-scoped is for everything except steps, which should be job-scoped, the job scope was actually introduced for the sole reason to support JSR 352, which is was removed in v5. This is really a discussion for another thread, but if someone is using the job scope, then she/he is doing something wrong. |
Resolves #3900 Signed-off-by: Mahmoud Ben Hassine <[email protected]>
fmbenhassine
added
the
for: backport-to-5.1.x
Bug description
I have a
Jobthat contains aStepthat is annotated with@JobScope(to be able to inject job parameters).Using
JobOperator.stop()from another thread to stop that job fails with the following exception:Environment
Spring Batch: 4.3.2
Steps to reproduce
JobExecution).JobOperator.stop()to stop that job.Expected behavior
Stopping the job works, regardless of the scope of its steps.
Minimal Complete Reproducible example
Sample project:
demo.zip
The project contains a job-scoped step. A
CommandLineRunnercreates aJobLauncherthat launches jobs asynchronously.Then, the main thread waits two seconds before it calls
JobOperator.stop()../mvnw spring-boot:runJobOperator.stop()is called and fails with the exception above.The text was updated successfully, but these errors were encountered: