ca.uhn.hl7v2.parser
Class DefaultModelClassFactory

java.lang.Object
  ca.uhn.hl7v2.parser.DefaultModelClassFactory

All Implemented Interfaces:

ModelClassFactory, java.io.Serializable

public class DefaultModelClassFactory
extends java.lang.Object
implements ModelClassFactory

Default implementation of ModelClassFactory. See packageList() for configuration instructions.

Version:

$Revision: 1.1 $ updated on $Date: 2006/12/14 20:10:26 $ by $Author: jamesagnew $

Author:

Bryan Tripp

See Also:

Serialized Form

Constructor Summary

DefaultModelClassFactory()

Method Summary

java.lang.Class	getGroupClass(java.lang.String theName, java.lang.String theVersion)
java.lang.Class	getMessageClass(java.lang.String theName, java.lang.String theVersion, boolean isExplicit) Attempts to return the message class corresponding to the given name, by searching through default and user-defined (as per packageList()) packages.
java.lang.Class	getSegmentClass(java.lang.String theName, java.lang.String theVersion)
java.lang.Class	getTypeClass(java.lang.String theName, java.lang.String theVersion)
static java.lang.String[]	packageList(java.lang.String version) Lists all the packages (user-definable) where classes for standard and custom messages may be found.

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Constructor Detail

DefaultModelClassFactory

public DefaultModelClassFactory()

Method Detail

getMessageClass

public java.lang.Class getMessageClass(java.lang.String theName,
                                       java.lang.String theVersion,
                                       boolean isExplicit)
                                throws HL7Exception

Attempts to return the message class corresponding to the given name, by searching through default and user-defined (as per packageList()) packages. Returns GenericMessage if the class is not found.

It is important to note that there can only be one implementation of a particular message structure (i.e. one class with the message structure name, regardless of its package) among the packages defined as per the packageList() method. If there are duplicates (e.g. two ADT_A01 classes) the first one in the search order will always be used. However, this restriction only applies to message classes, not (normally) segment classes, etc. This is because classes representing parts of a message are referenced explicitly in the code for the message class, rather than being looked up (using findMessageClass() ) based on the String value of MSH-9. The exception is that Segments may have to be looked up by name when they appear in unexpected locations (e.g. by local extension) -- see findSegmentClass().

Note: the current implementation will be slow if there are multiple user- defined packages, because the JVM will try to load a number of non-existent classes every parse. This should be changed so that specific classes, rather than packages, are registered by name.

Specified by:

getMessageClass in interface ModelClassFactory

Parameters:

name - name of the desired structure in the form XXX_YYY

version - HL7 version (e.g. "2.3")

isExplicit - true if the structure was specified explicitly in MSH-9-3, false if it was inferred from MSH-9-1 and MSH-9-2. If false, a lookup may be performed to find an alternate structure corresponding to that message type and event.

Returns:

corresponding message subclass if found; GenericMessage otherwise

Throws:

HL7Exception - if the version if not recognized or an appropriate class can not be found

getGroupClass

public java.lang.Class getGroupClass(java.lang.String theName,
                                     java.lang.String theVersion)
                              throws HL7Exception

Specified by:

getGroupClass in interface ModelClassFactory

Parameters:

theName - name of group

theVersion - HL7 version

Returns:

a class that implements the specified group

Throws:

HL7Exception - if the version if not recognized or an appropriate class can not be found

See Also:

ModelClassFactory.getGroupClass(java.lang.String, java.lang.String)

getSegmentClass

public java.lang.Class getSegmentClass(java.lang.String theName,
                                       java.lang.String theVersion)
                                throws HL7Exception

Specified by:

getSegmentClass in interface ModelClassFactory

Parameters:

theName - name of segment

theVersion - HL7 version

Returns:

a class that implements the specified segment

Throws:

HL7Exception - if the version if not recognized or an appropriate class can not be found

See Also:

ModelClassFactory.getSegmentClass(java.lang.String, java.lang.String)

getTypeClass

public java.lang.Class getTypeClass(java.lang.String theName,
                                    java.lang.String theVersion)
                             throws HL7Exception

Specified by:

getTypeClass in interface ModelClassFactory

Parameters:

theName - name of type

theVersion - HL7 version

Returns:

a class that implements the specified type

Throws:

HL7Exception - if the version if not recognized or an appropriate class can not be found

See Also:

ModelClassFactory.getTypeClass(java.lang.String, java.lang.String)

packageList

public static java.lang.String[] packageList(java.lang.String version)
                                      throws HL7Exception

Lists all the packages (user-definable) where classes for standard and custom messages may be found. Each package has subpackages called "message", "group", "segment", and "datatype" in which classes for these message elements can be found.

At a minimum, this method returns the standard package for the given version. For example, for version 2.4, the package list contains ca.uhn.hl7v2.model.v24. In addition, user-defined packages may be specified for custom messages.

If you define custom message classes, and want Parsers to be able to find them, you must register them as follows (otherwise you will get an exception when the corresponding messages are parsed). For each HL7 version you want to support, you must put a text file on your classpath, under the folder /custom_packages, named after the version. For example, for version 2.4, you might put the file "custom_packages/2.4" in your application JAR. Each line in the file should name a package to search for message classes of that version. For example, if you work at foo.org, you might create a v2.4 message structure called "ZFO" and define it in the class org.foo.hl7.custom.message.ZFO. In order for parsers to find this message class, you would need to enter the following line in custom_packages/2.4:

org.foo.hl7.custom

Packages are searched in the order specified. The standard package for a given version is searched last, allowing you to override the default implementation. Please note that if you create custom classes for messages, segments, etc., their names must correspond exactly to their names in the message text. For example, if you subclass the QBP segment in order to add your own fields, your subclass must also be called QBP. although it will obviously be in a different package. To make sure your class is used instead of the default implementation, put your package in the package list. User-defined packages are searched first, so yours will be found first and used.

It is important to note that there can only be one implementation of a particular message structure (i.e. one class with the message structure name, regardless of its package) among the packages defined as per the packageList() method. If there are duplicates (e.g. two ADT_A01 classes) the first one in the search order will always be used. However, this restriction only applies to message classes, not segment classes, etc. This is because classes representing parts of a message are referenced explicitly in the code for the message class, rather than being looked up (using findMessageClass() ) based on the String value of MSH-9.

Throws:

HL7Exception