You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have a complex file format where there are lines that are comments and should not be read, but the format of these comments can't be determined using simple startsWith comparisons.
It would be great if the FlatFileItemReader could take a class instance in a setter that implements interface, let's say CommentDetector (and provide the current functionality by default) so that we could supply our own CommentDetector instance. The interface would be like
where the line parameter is, well the line that should be determined if it is a comment or not and comments array containing the comment line prefixes that the reader already has.
Does not affect backwards compatibility, makes it possible to implement custom detection logic without extending. (Which currently is hard/impossible because the methods that contain the detection logic are private.)
Which currently is hard/impossible because the methods that contain the detection logic are private
I don't think we need to introduce a new concept for this use case (trying to avoid API bloat). I suggest to change the visibility of the FlatFileItemReader#isComment method and the FlatFileItemReader.comments field to protected. With that, it should be possible to override the method and customize the comment detection logic as needed.
fmbenhassine
changed the title
Let FlatFileItemReader comment detection logic be customizable [BATCH-2468]
Let FlatFileItemReader comment detection logic be customizable
Jul 24, 2020
Ville Virtanen opened BATCH-2468 and commented
We have a complex file format where there are lines that are comments and should not be read, but the format of these comments can't be determined using simple startsWith comparisons.
It would be great if the FlatFileItemReader could take a class instance in a setter that implements interface, let's say CommentDetector (and provide the current functionality by default) so that we could supply our own CommentDetector instance. The interface would be like
where the line parameter is, well the line that should be determined if it is a comment or not and comments array containing the comment line prefixes that the reader already has.
Does not affect backwards compatibility, makes it possible to implement custom detection logic without extending. (Which currently is hard/impossible because the methods that contain the detection logic are private.)
No further details from BATCH-2468
The text was updated successfully, but these errors were encountered: