Announcement Announcement Module
Collapse
No announcement yet.
skippable-exception-classes not recognizing IncorrectTokenCountException Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • skippable-exception-classes not recognizing IncorrectTokenCountException

    When I added 'IncorrectTokenCountException' as a 'skippable-exception-classes' it is not skipping the record. But if I add 'FlatFileParseException' it works fine. Not sure whether this is a bug or correct behavior.

  • #2
    There must be more to this story than we know yet. Can you post some more details?

    Comment


    • #3
      I am also seeing this with 2.1.1 (w/ spring-integration 1.0). If I change the skippable class to java.lang.Exception my job completes. Having the FlatFileFormatException in there causes the job to fail once the exception is thrown.

      Also, I am able to reproduce http://jira.springframework.org/browse/BATCH-1418 in 2.1.1.

      Code:
       <batch:job id="processFeed" job-repository="jobRepository">
              <batch:step id="parse">
                  <batch:tasklet transaction-manager="batchTransactionManager">
                      <batch:chunk reader="csvWithHeaderReader" writer="scrubInputChannelWriter" commit-interval="2" skip-limit="50" retry-limit="50">
                          <batch:skippable-exception-classes>
                              <!-- skip bogus formatted lines -->
                              <batch:include class="org.springframework.batch.item.file.transform.FlatFileFormatException"/>
                          </batch:skippable-exception-classes>
                          <batch:retryable-exception-classes>
                              <batch:include class="org.springframework.remoting.RemoteAccessException"/>
                              <batch:include class="org.springframework.remoting.RemoteConnectFailureException"/>
                              <batch:include class="java.net.ConnectException"/>
                          </batch:retryable-exception-classes>
                      </batch:chunk>
                  </batch:tasklet>
              </batch:step>
          </batch:job>
      
      <bean id="tokenizer" class="org.springframework.batch.item.file.transform.DelimitedLineTokenizer">
              <constructor-arg>
                  <util:constant static-field="org.springframework.batch.item.file.transform.DelimitedLineTokenizer.DELIMITER_COMMA"/>
              </constructor-arg>
          </bean>
          
          <!-- Extracts first line of CSV file and uses the values as the keys in the resulting
               field set. -->
          <bean id="csvWithHeaderReader" class="org.springframework.batch.item.file.FlatFileItemReader" scope="step">
              <property name="resource" value="#{jobParameters['fileName']}"/>
              <property name="lineMapper">
                  <bean class="org.springframework.batch.item.file.mapping.DefaultLineMapper">
                      <property name="lineTokenizer" ref="tokenizer"/>
                      <property name="fieldSetMapper">
                          <bean class="com.dealer.inventoryfeeds.processor.InventoryScrubItemFieldSetMapper">
                              <property name="jobParameters" value="#{jobParameters}"/>
                          </bean>
                      </property>
                  </bean>
              </property>
              <property name="linesToSkip" value="1"/>
              <property name="skippedLinesCallback">
                  <bean class="com.dealer.inventoryfeeds.processor.LineTokenizerHeaderCallback">
                      <property name="tokenizer" ref="tokenizer"/>
                  </bean>
              </property>
          </bean>

      Comment


      • #4
        Apparently that is the expected behaviour. The DefaultLineMapper wraps all exceptions in the field set mapper in a FlatFileParseException (not FlatFileFormatException).

        To be more specific about the exception type in the field set mapper you would have to provide a custom LineMapper that didn't wrap the exception.

        Comment

        Working...
        X