Issue Details (XML | Word | Printable)

Key: BATCH-348
Type: Bug Bug
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Lucas Ward
Reporter: Douglas C. Kaminsky
Votes: 0
Watchers: 0
Operations

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

Remove close method from AbstractItemReader

Created: 09/Feb/08 11:02 PM   Updated: 07/Aug/08 10:06 AM
Component/s: Infrastructure
Affects Version/s: 1.0.0.m4
Fix Version/s: 1.0.0.m5

Time Tracking:
Not Specified


 Description  « Hide
AbstractItemReader is no longer needed - as AbstractItemProvider it had recover() and close() methods.

recovery is now handled by ItemRecoverer and close is handled by ItemStream -- recover was already removed with the rename, but the close method remains.

Since the close method is a contract of ItemStream and not of ItemReader, it doesn't make sense for AbstractItemReader, which doesn't implement ItemStream, to have a default implementation. This leaves no functionality for this layer of abstraction, leading me to believe it should be removed entirely.

 All   Comments   Work Log   Change History   FishEye   Builds      Sort Order: Ascending order - Click to sort in descending order
Dave Syer added a comment - 10/Feb/08 05:53 AM
It is still useful to have the abstract class - it it used extensively to create stubs for testing (across multiple projects), and this class protects clients from changes to the ItemReader interface. I removed the close() method.

Douglas C. Kaminsky added a comment - 10/Feb/08 05:49 PM
How is an empty class more useful than an interface for testing? Couldn't you just as easily make a dynamic mock from the ItemReader interface?

Additionally, the ItemReader interface should be frozen as of each major revision (i.e. 1.0), at which point there is no need to protect clients from changes since no changes should occur.

Dave Syer added a comment - 11/Feb/08 02:38 AM
Agreed that the interface should not change in 1.0.*. I'm more concerned with protecting internal usage (test cases) than clients.

Lucas Ward added a comment - 25/Feb/08 11:08 AM
This is removed in the AbstractItemReader and ItemWriter. I removed close() from a few other places as well where it didn't belong. Please create a new issue if you see any other problems.

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