InitializingTasklet, DisposableTasklet [BATCH-106]

[spring-projects-issues]

Douglas C. Kaminsky opened BATCH-106 and commented

Request for 2 new interfaces to mirror Spring functionality:

InitializingTasklet: along the lines InitializingBean, defines a contract for some sort of init method which is called once at the beginning of the Step before execute is called for the first time
DisposableTasklet: along the lines of DisposableBean, defines a contract for some sort of destroy method which is called once at the end of the Step after execute is called for the last time

These should be auto-wired via reflection so that if I define a Tasklet which implements either or both of these interfaces, the appropriate method will be called automatically without further effort within the default executors.

Sample use cases: Opening/closing file handles, performing file copy/move/rename operations at the beginning or end of some processing

Existing solutions so far seem insufficient to handle this -

1. write my own version of tasklet which wraps this and keys off of ExitStatus - this is a hack and non-uniform, which defeats the purpose of using Spring Batch
2. use a RepeatInterceptor, which forces me to separate logic between the tasklet and the step execution instead of being centrally located - also, seems that I'd have to use a non-default StepExecutor to do this
3. wire file handles in as beans - doesn't allow dynamic locating and opening of files

Possibly related issue: BATCH-45 (POJO adaptor)

---

Affects: 1.0-m2

[spring-projects-issues]

Douglas C. Kaminsky commented

Forgot #4 --

4. Implement file operations using AOP - this is not easily maintainable and would take too much time to implement properly (if you guys want to do this and provide some sort of file tracking API, I wouldn't object)

[spring-projects-issues]

Dave Syer commented

The functionality described is provided already by the Spring bean lifecycle if the bean is marked as scope="step". You can use InitializingBean/DisposableBean or init-methd/destroy-method. The only restriction is that the bean cannot be an inner bean. We will try and get that changed, or introduce custom namespace features that work around it, but that's another story.

[spring-projects-issues]

Douglas C. Kaminsky commented

Thanks for the clarification. This makes a lot of sense. Is the inner bean problem an open JIRA issue?

[spring-projects-issues]

Dave Syer commented

Assume closed as resolved and released