Dynamic Custom Model Class Factories with Groovy

Custom HL7 message structures are added by defining an org.openehealth.ipf.modules.hl7.config.CustomModelClasses bean in a custom Spring application context file. This bean definition represents a mapping with a message structure version as a mapping-key and the package name of custom model classes as a mapping-value.

These custom message structures have priority over the existing message structures.

    <bean id="customClasses"
          class="org.openehealth.ipf.modules.hl7.config.CustomModelClasses">
        <property name="modelClasses">
            <map>
                <entry key="2.5">
                    <list>
                        <value>org.openehealth.ipf.modules.hl7.parser.test.hl7v2.def.v25</value>
                    </list>
                </entry>
            </map>
        </property>
    </bean>

The custom model classes from the given package will be picked up by the CustomModelClassesRegistrar and automatically added to the shared CustomModelClassFactory. Without its customModelClassFactory property, the registrar configures every CustomModelClassFactory bean of the application context. The Spring context META-INF/spring/hl7-context.xml shipped with ipf-modules-hl7 declares both beans, and in Spring Boot applications the HL7v2 starter auto-configures them. If a Spring Boot application declares its own CustomModelClassFactory bean, it must construct it with a mutable map, because the registrar adds the contributed packages to that map.

Note: Up to IPF 5.3, the custom model classes were picked up by the CustomModelClassFactoryConfigurer, which had to be registered with a SpringConfigurationPostProcessor. This is deprecated since IPF 6.0; see the IPF 6.0 migration guide.

It is also possible to use theGroovyCustomModelClassFactory and mix script-based with class-based model class definitions:

      <bean id="groovyCustomModelClassFactory"
            class="org.openehealth.ipf.modules.hl7.parser.GroovyCustomModelClassFactory">
          <constructor-arg ref="javaCustomModelClassFactory"/> <!-- fallback -->
      </bean>

      <bean id="javaCustomModelClassFactory"
            class="org.openehealth.ipf.modules.hl7.parser.CustomModelClassFactory" >
      </bean>

      <bean id="registrar"
            class="org.openehealth.ipf.modules.hl7.config.CustomModelClassesRegistrar">
        <property name="customModelClassFactory" ref="groovyCustomModelClassFactory" />
      </bean>

Up to IPF 5.3, use a CustomModelClassFactoryConfigurer with the same property instead, and register it with the SpringConfigurationPostProcessor:

      <bean id="configurer"
            class="org.openehealth.ipf.modules.hl7.config.CustomModelClassFactoryConfigurer">
        <property name="customModelClassFactory" ref="groovyCustomModelClassFactory" />
      </bean>

      <bean id="postProcessor"
            class="org.openehealth.ipf.commons.spring.core.config.SpringConfigurationPostProcessor">
          <property name="springConfigurers">
            <list>
              <ref bean="configurer" />
            </list>
          </property>
      </bean>

Now the custom Spring context file can have custom model classes as both scripts and compiled classes:

      <bean id="customClasses"
        class="org.openehealth.ipf.modules.hl7.config.CustomModelClasses">
        <property name="modelClasses">
          <map>
            <entry key="2.5"> <!-- compiled classes -->
              <list>
                <value>org.openehealth.ipf.modules.hl7.parser.compiled.hl7v2.def.v25</value>
              </list>
            </entry>
            <entry key="2.4"> <!-- groovy scripts -->
              <list>
                <value>org.openehealth.ipf.modules.hl7.parser.notcompiled.hl7v2.def.v24</value>
              </list>
            </entry>
          </map>
        </property>
      </bean>