Issue Details (XML | Word | Printable)

Key: BATCH-378
Type: Improvement Improvement
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Dave Syer
Reporter: Lucas Ward
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Spring Batch

RepeatListener is confusing and too generic to use for 'intercepting' a step

Created: 21/Feb/08 10:39 PM   Updated: 07/Aug/08 10:06 AM
Component/s: Core
Affects Version/s: 1.0.0.m4
Fix Version/s: 1.0.0.m5

Time Tracking:
Original Estimate: 1d
Original Estimate - 1d
Remaining Estimate: 1d
Remaining Estimate - 1d
Time Spent: Not Specified
Remaining Estimate - 1d


 Description  « Hide
Currently, the ItemOrientedStep can only be intercepted by using AOP (which can be applied around Step.execute, PlatformTransactionManager, and the reader and writer) or using RepeatListeners around one of the two RepeatTemplates in the step. I have two issues with this: 1) RepeatListener is too generic and 2) It causes confusion.

I don't mean to say that they're bad in general. If you look at the RepeatTemplates by themselves, they make a lot of sense, and are extremely useful. However, when they're used as the mechanism for intercepting the step execution, they cause issues. The problem is really because of how they're applied. Just for clarity, the interface is repeated below:

void before(RepeatContext context);

void after(RepeatContext context, ExitStatus result);

void open(RepeatContext context);

void onError(RepeatContext context, Throwable e);

void close(RepeatContext context);

My central problem is this: applying a RepeatListener at either the StepOperations has a completely different meaning from applying it at a ChunkOperations, which is confusing. For example, before and after on a RepeatListener in the stepOperations is exactly the same same as open and close on a RepeatListener on the chunkOperations, it all depends upon where you apply it. Furthermore, it has absolutely no domain meaning. If I was going to create a 'StepListener' interface that solved this problem it would have an interface like the one below:

void beforeChunk(RepeatContext context);

void afterChunk(RepeatContext context, ExitStatus result);

void beforeItem(RepeatContext context);

void afterItem(RepeatContext context, ExitStatus result);

void onError(RepeatContext context, Throwable e);

void close(RepeatContext context);

void open(RepeatContext context);

void onError(RepeatContext context, Throwable e);

//Returning ExitStatus would allow for modifying the status that's returned.
ExitStatus close(RepeatContext context);

You could potentially break this up into two interfaces if you want to (StepListener and ChunkListener), however, the effect would be the same regardless. it would have domain meaning (i.e. before chunk, after chunk) and there would be only one place to apply it, the step. I think this would go a long way towards making it easier to understand, while also solving a couple of other issues.

 All   Comments   Work Log   Change History   FishEye   Builds      Sort Order: Ascending order - Click to sort in descending order
Douglas C. Kaminsky added a comment - 22/Feb/08 08:35 PM
I think that separating the RetryTemplate, RepeatTemplate, their respective listeners and AOP interceptors into a separate package makes more sense - I think of these templates mostly as tools that aid us in achieving a goal, not as domain objects that are even specifically related to batch. As we have seen on at least one occasion, end users have found uses for these constructs completely outside of batch operations, which is great since they are pretty well-designed and very useful.

To that end, I say leave the listeners intact and add the two mentioned interfaces (the StepListener and ChunkListener) and potentially a third one that's item-related (e.g. ItemListener). For symmetry, I would also offer an AOP interceptor version (ala RepeatOperationsInterceptor) as an alternative which makes the behavior much more configurable and less programmatic, which is very Spring-y.

Ben Hale added a comment - 25/Feb/08 04:55 AM
We can't actually add those listeners if we expect the templates to continue to be 'infrastructure'. I think this is where the whole talk about 'infrastructure' really breaks down. We might be keeping things separate from compile-time dependency standpoint, but we continue pushing batch-specific requirements down on it. So for example, I'm not sure how we'll be able to share an ItemReader or ItemWriter with the Spring Integration project if it's got all of this stuff about stream state. On the same token, I can't imagine that it's very 'generic' for our shared library to have a RetryTemplate which has ChunkListener.

To be clear, I think that either we stop forcing requirements on them so are truly generic, or we stop attempting to make the generic.

Lucas Ward added a comment - 25/Feb/08 09:30 AM
Ben, I'm not advocating modifying the listeners for either retry template or repeat template. I'm advocating not using them. Creating our own listener and applying it is very trivial, and as you say, we can't do it generically in a way that would let these infrastructure items still exist separately. So, I think creating our own and not using the repeat template listener is a better option.

Regarding readers and writiers, I agree about the ItemStream interface, and have been cleaning it up. I think with a few more change it could be much more usable outside of of spring batch step.

Dave Syer added a comment - 29/Feb/08 02:11 AM - edited
Added StepListener to TaskletStep. Other BatchListeners in ItemOrientedStep. These are a much better way to get hold of execution environment context than *Aware interfaces and step scope (so these are going to be removed).

Also to do: remove instanceof checks and needless delegation of listener methods (principally ItemStream) - insist instead that injected dependencies are properly registered as listeners in the Step.

Lucas Ward added a comment - 02/Mar/08 11:21 PM
I added some code to ensure that afterStep was called correctly and made a few adjustments to how SimpleJob handles failures. Since I think everyone is happy with the interface, this issue is being marked resolved. There's still a few things being tweaked in the StepFactory, but that should be a separate issue.

Dave Syer added a comment - 07/Aug/08 10:06 AM
Assume closed as resolved and released