[#BATCH-563] ItemOrientedStep can be TaskletStep + ItemOrientedTasklet

Spring Batch

BATCH-675

ItemOrientedStep can be TaskletStep + ItemOrientedTasklet

Created: 07/Apr/08 03:58 AM Updated: 17/Jul/08 06:29 AM

Component/s:

Core

Affects Version/s:

1.0.0

Fix Version/s:

None

Time Tracking:

Original Estimate:

0.5d

Remaining Estimate:

0.5d

Time Spent:

Not Specified

Description

« Hide

After consolidating step implementations in ~~BATCH-546~~ I think we don't really need two separate step implementations - the item-oriented execution logic can be encapsulated as ItemOrientedTasklet rather than ItemOrientedStep.

The precondition would be to add open() and close() methods to Tasklet interface, which makes good sense I think - when implementing a Tasklet there will often be some kind of resource allocation and releasing i.e.boilerplate and error-prone try/catch/finally structure that the framework can handle instead.

If we merge ItemOrientedStep and TaskletStep as described above, the AbstractStep is likely to become redundant as well - the abstract methods will just delegate to corresponding Tasklet methods.

All

Comments

Work Log

Change History

FishEye

Builds

Sort Order:

[ Permlink | « Hide ]

Lucas Ward added a comment - 07/Apr/08 09:49 AM

I have to say I'm not sure I like the idea of pushing the processing logic back into the Tasklet from where we had it before. I suppose it's a difference between having one step with multiple Tasklet implementations or multiple Step implementations. It seems like the former would be a step backwards. I know the addition of FactoryBeans helps somewhat, but I'm just not sure I like taking the Tasklet and rebranding it as essentially the StepExecutor, only different. I think having multiple Step implementations is still the right way to go.

[ Permlink | « Hide ]

Robert Kasanicky added a comment - 07/Apr/08 10:13 AM

I think it is largely an "inheritance vs. composition" question - AbstractStep currently declares 3 abstract methods, we could instead define an interface declaring these methods and inject a collaborator into the step.

[ Permlink | « Hide ]

Douglas C. Kaminsky added a comment - 07/Apr/08 10:33 AM

I had mixed feelings when this change was first made in the opposite direction... but now that I think about it I like the idea of ItemOrientedStep much better than ItemOrientedTasklet... here's my reasoning:

1. It makes item-oriented processing a top-level concept
...

Okay, that's really it - item-oriented processing is a top-level batch processing concept - it is the most common use case and it's a best practice... (that is, other transaction boundaries aside -- ChunkedStep is still item-oriented processing).

It also makes me feel less gross about the Tasklet paradigm - it really gives the Tasklet a specific role as a means to accomplish an arbitrary not-necessarily-item-related task rather than as an all-encompassing blank abstraction. Look at the API - how many Tasklet-related classes do you see? How many item-oriented processing collaborators, helpers, support classes, adapters, implementations, etc. do you see? This alone illustrates the importance of each in the grand scheme of things, in my opinion. As it stands now, the Tasklet is a custom extension point, not a fundamental stereotype, and I like it much better this way.

There IS a second, much-less-convincing argument, which is that it's just more convenient to configure:

<bean class="...ItemOrientedStep>

</bean>

VS.

<bean class="...SimpleStep>
<bean class="...ItemOrientedTasklet">

</bean>
</bean>

but I maintain that it should remain as is on merit of making items a first-class paradigm alone.

[ Permlink | « Hide ]

Dave Syer added a comment - 17/Jul/08 06:29 AM

I am OK with inheritance for what is basically an internal implementation detail. I did make the open/close methods concrete in AbstractStep though (so trivial subclasses don't have to implement them).