Calling .encode on a message seems to influence the structure of the message. Running the following code exploits the issue:
package test;
import java.io.File;
import java.io.IOException;
import java.nio.charset.Charset;
import org.junit.Assert;
import org.junit.Test;
import ca.uhn.hl7v2.HL7Exception;
import ca.uhn.hl7v2.model.Message;
import ca.uhn.hl7v2.parser.PipeParser;
import com.google.common.io.Files;
public class ProfileTest {
@Test public void detectEncodeBug() throws HL7Exception, IOException { Message incoming = new PipeParser().parse(Files .toString(new File("some-message.hl7"), Charset.forName("UTF-8"))); String structureBeforeEncode = incoming.printStructure(); incoming.encode(); String structureAfterEncode = incoming.printStructure(); Assert.assertEquals(structureBeforeEncode, structureAfterEncode); }
}
What becomes apparent is that empty segments are created when calling encode which has a great impact when doing conformance profile validation as some segments are suddenly apparent.
Thanks for the report, I've confirmed this and checked the provided test case into NewPipeParserTest.java.
The source of this bug seems to be line 671 in PipeParser.java:
source.get(nextName, 0);
Commenting out this line fixes the issue, but I'm not sure what regressions that would cause. Need to investigate that before committing such a fix, so this might need to wait until post-2.2
Some archaeology: This dates to back to 2011, introduced with rev. 335 and the comment "Add forced encode mode". I think it was about changing the "encode empty segments" config into a forcing encoding for dedicated empty groups/segments.
When I disable the line in PipeParser, at least the testEncodeWithForceEncoding Tests in the NewPipeParserTest class (that were introduced with the same revision) still work. So chances are that the side effects are limited.
From a logical perspective, I think that encoding a (unchanged) parsed message should not modify it.
committed the change