Announcement Announcement Module
Collapse
No announcement yet.
FlatFileItemReader: Parsing file containing sequnce of characters as record separator Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • FlatFileItemReader: Parsing file containing sequnce of characters as record separator

    I have a file that needs to be parsed and broken into Objects. I'm using FlatFileItemReader for this.

    The problem is that the file contains this sequence of characters as record separator - «{BEG}«
    and « as field separator
    Configuring «{BEG}« string as record separator does not work, it just returns the very first line of file and stops.

    I'm guessing this is because the file contains no new lines and the code internally still depends on plain old readLine() which requires a new line character.

    Can someone suggest a clean way to handle this?

    Sample data:
    item11«item12«item13««{BEG}«item21«item22«item23«« {BEG}«item31«item32«item33««{BEG}«

  • #2
    How about:

    Code:
    sed -ie 's/«{BEG}«/\n/g' myfile.txt

    Comment


    • #3
      Thanks Dave

      I'm looking for a java/spring batch based solution. Ideally, I would like to just configure and wire existing classes into some reader or write the bare minimum classes of my own which could be plugged into batch framework. While this is not a difficult problem to solve, I'm just looking for a clean solution and I want to be sure that I'm not missing any existing feature of spring batch before writing my own class.

      What I'm wondering is Record Separator Policy is supposed to do exactly this - being able to customize record separator and not depend on newlines. But it isn't working as expected.

      Comment


      • #4
        I couldn't find a JIRA for this so I created one (http://jira.springframework.org/browse/BATCH-1356). In the meantime you have to duplicate a lot of FlatFileItemReader, and provide it with a way to scan a character stream that doesn't depend on java.io.BufferedReader.

        Comment


        • #5
          Thanks Dave, I see that it has been fixed in the latest release.

          Comment

          Working...
          X