That was quite a long post, but it looks to me like you're generally happy except for two points:

1) If calling fieldSet.read* fails, you get a FlatFileParseException, which contains the original line and the line number of the file, but you don't get the FieldSet itself. I'm not quite sure I understand why this is a problem? What advantage would having the FieldSet give you over having the original line itself? Since trying to parse the FieldSet has already caused an error, it seems like all you would want to do is log out the original line that was parsed into the fieldset?

2) If you are able to create an 'Item' successfully from the FieldSetMapper (or any other ItemReader) and it fails Validation, you have no way of getting the item from any Spring Batch listener. This is a valid issue, and I hope it's tracked in Jira (if not, please add it). However, it's an interesting issue from an API standpoint. There's a general contract in the ItemReader API that it either returns an item (i.e. reads successfully) or fails by throwing an Exception. I don't see anyway to support this scenario without some fairly major changes to the api so that you could have a validator separate from the ItemReader but before the ItemWriter. This would be part of a much bigger change that would have to be handled as a 2.0 issue. However, there may be a much better workaround for 1.1. There's an issue here to be able to select which exceptions cause rollback or not. Therefore, you could put your validation in the ItemWriter, and list a validation exception as something that shouldn't cause rollback. In that way you would have your item to log out, but wouldn't have the extra unnecessary rollback. I actually have a client doing this now by inserting a custom ExceptionHandler in the chunkOperations, so it's doable even in 1.0, but it should be much cleaner in 1.1.