ItemRecoverer interface

[gpitteloud]

I am looking at differences from 1.0.x to 1.1.x, and noticed that I cannot set an item recoverer in step factorybean anymore.

While I see the ItemRecoverer interface is still present, it is only used in retry invoked through a new interceptor mechanism.

So, my questions are:

1. How do I set up a ItemRecoverer in a step ?
2. How is the interceptor mechanism set up in spring-batch ? How is it used ?

Thanks in advance for your answers.

[Dave Syer]

You could treat ItemRecoverer as deprecated (sorry we didn't mark it explicitly - I really didn't think anyone was using it). ItemSkipListener is the revovery path in a step since 1.1.

The interceptor is not used by the core framework (i.e. none of the step implementations etc. in spring-batch-core use it). It is there as a convenient way of adding retry to business logic generally speaking (so not tied to a step). There are some changes in the interfaces again in 2.0, and we expect the whole retry infrastructure to move to Spring Core.

[gpitteloud]

Thanks for the reply.

This is all fine, as I have an ItemReader that both implemented ItemRecoverer and SkipListener, with actually the same code in the implementation of both SkipListener onSkip methods and ItemRecoverer recover method. I will then simply remove the reference to ItemRecoverer interface in my reader.

[gpitteloud]

Is it the same for the interface NewItemIdentifier (which formerly was FailedItemIdentifier) ? I only see the interface being used in the interceptor mechanism.

But then, how do I specify a strategy for identifying items that were already presented ?

[Dave Syer]

Correct me if I'm wrong, but I doubt if it was really all that important. The name was always confusing as the responsibility was never to identify failed items (the retry template / policy takes care of that, always did and always will). The NewItemIdentifier is only an optimisation, mainly aimed at people using clustered caches for the RetryContextCache. If you are using SkipLimitStepFactoryBean I doubt the optimisation has any impact at all anyway - it only reduces the item processing time by the look up of the item in a hash map.

[gpitteloud]

Looking at 1.0 code, this is exactly where I came to : it is a hint to prevent a cache hit. I actually implemented this method because I had a way to quickly answer based on the item whether it failed or not (just like the JMS reader does by inspecting the JMSRedelivered flag), but this is not necessary.

I think I will drop this interface from my reader too.
Thanks for the information.