Results 1 to 10 of 17

Thread: skipListener : howto get the item read

Hybrid View

  1. #1
    Join Date
    Jul 2005
    Posts
    156

    Red face skipListener : howto get the item read

    Hello,

    Interface SkipListener in 1.0.0-FINAL looks really interesting.

    My need is to persist the skipped items in a database (in order to determine easily which items where skipped and what action I should do).

    The first question I have to answer is how to get the skipped item.
    I'll get it from SkipListener#onSkipInWrite(Object,Throwable) method if there was an error during writing process.
    But if the error occurs in the read process, I'll be screwed !
    Since I'm going to use ValidatingItemReader, I'm expecting that most skip errors will be during the read process (item validation error).

    I've quickly implemented a solution base on aspects. An ItemContextInterceptor is applied on every ItemRead#read and every FieldSetMapper#mapLine
    This aspect just add the returned element to a ThreadLocal ItemContext.
    Then, whenever SkipListener is called, I've got every read item in the chain and can persist them to the database.

    Is it a good solution ? Personnally I'm not too fond on relying on aspects for this (a bit intrusive). Perhaps I've missed something in the framework.

    If yes, can we imagine being part in the future of Spring Batch (if there's a common need of course ) ?

    Thanks for the feedback

  2. #2
    Join Date
    Jun 2005
    Posts
    4,230

    Default

    That's a pretty interesting and common use case - a delegating item reader with some need to listen to validation / binding errors. I think you might see something in the framework at some point if you put it in JIRA.

  3. #3
    Join Date
    Dec 2006
    Posts
    1,061

    Default

    It's definitely interesting. The way I see if you have two problems:

    1) failed to 'parse' and make an item. This might be because a line was bad in a text file. In this case there isn't too much we can do. If you look at FlatFileParsingException, it contains the original line that can be helpful when logging, but I'm not sure what we can do beyond that.

    2) It failed validation. In my mind it's the difference between 'well-formed' and valid. Problem 1 is a 'well-formedness' issue, and this is whether or not the returned item is valid. I'm starting to wondering if adding a validator wouldn't be better achieved by adding some type of functionality to the afterRead method of ItemReadListener. Perhaps something like, if an exception is thrown the item will be skipped?

  4. #4
    Join Date
    Jul 2005
    Posts
    156

    Default

    Created http://jira.springframework.org/browse/BATCH-540.

    If you look at FlatFileParsingException, it contains the original line that can be helpful when logging
    Cool ! I was going to aspectize (aspectize = well formed english ?) FlatFileItemReader#readLine().
    Horrible since it's a private method (I don't even know if we can add an aspect to a private method).

    I'm starting to wondering if adding a validator wouldn't be better achieved by adding some type of functionality to the afterRead method of ItemReadListener.
    This solution is fine when considering ValidatingItemReader.
    But if I'm implementing my own custom reader, should I then create my own and separate ItemReadListener#afterRead to implement my custom validation / business rules ?
    Please, note that I have really no experience with Spring Batch so I can be (and I am surely) mistaken...

    Thanks very much for you quick feedback, really appreciated !

  5. #5
    Join Date
    Dec 2006
    Posts
    1,061

    Default

    I suppose you could throw some kind of specific ValidationException that contains the original item. It would require an instanceof check though.

  6. #6

    Default

    I think ValidationException should skip the item by default. Is a common case.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •