I was previously using 1.4 jars for UNEDIFACT parsing and the UNA segment at the beginning of edi messages was being parsed ok in order to override the default delimiters used by the parser. I am now trying to run with 1.5 jars but the UNA segment delimiters at the beginning of edi messages no longer seem to be being taken into account by the parser...
Could somebody confirm whether UNA delimiters are still being taken into account by the parser in 1.5+ jar versions or am I making a mistake somewhere?
I could be wrong but I think a bug may have been introduced in BufferedSegmentReader class in smooks-edisax-parser project since v1.4.1.
Before v1.4.1, edi messages with special code delimiters (i.e. 0x1C, 0x1D, 0x1F) could be parsed okay by EDIParser. However, in v1.4.1, a change was made in class BufferedSegmentReader's moveToNextSegment(boolean clearBuffer) method to ignore leading whitespaces (forwardPastWhitespace(c)). This has the effect that delimiter code characters may now be skipped over during the build of a segmentBuffer.
Can anyone verify whether this is in fact a possible problem or not? Does anyone know whether the smooks-edisax-parser project runs any Unit tests with edi messages which use special delimiter codes? (I believe these special delimiters are quite commonly used in industry!).