Variables are stored in the database in a 2-step approach :
user-java-object <---> converter <---> variable instance
Variables are stored in VariableInstances.
The members of VariableInstances are mapped to fields
in the database with hibernate. In the default configuration of jBPM,
6 types of VariableInstances are used:
DateInstance (with one java.lang.Date
field that is mapped to a Types.TIMESTAMP in the
database)
DoubleInstance (with one java.lang.Double
field that is mapped to a Types.DOUBLE in the
database)
StringInstance (with one java.lang.String
field that is mapped to a Types.VARCHAR in the
database)
LongInstance (with one java.lang.Long
field that is mapped to a Types.BIGINT in the
database)
HibernateLongInstance (this is used for
hibernatable types with a long id field. One java.lang.Object field is mapped
as a reference to a hibernate entity in the database)
HibernateStringInstance (this is used for
hibernatable types with a string id field. One java.lang.Object field is mapped
as a reference to a hibernate entity in the database)
Converters convert between java-user-objects
and the java objects that can be stored by the
VariableInstances. So when a process variable is set
with e.g. ContextInstance.setVariable(String variableName, Object value),
the value will optionally be converted with a converter. Then the converted
object will be stored in a VariableInstance.
Converters are implementations of the following
interface:
public interface Converter extends Serializable {
boolean supports(Object value);
Object convert(Object o);
Object revert(Object o);
}Converters are optional. Converters must be available to the jBPM class loader
The way that user-java-objects are converted and stored in
variable instances is configured in the file
org/jbpm/context/exe/jbpm.varmapping.properties.
To customize this property file, put a modified version in the root of
the classpath, as explained in the section called “Other configuration files”
Each line of the properties file specifies 2 or 3 class-names separated by spaces :
the classname of the user-java-object, optionally the classname of the converter
and the classname of the variable instance. When you refer your custom converters,
make sure they are in the jBPM class path.
When you refer to your custom variable instances, they also have to be in
the the jBPM class path and the hibernate
mapping file for org/jbpm/context/exe/VariableInstance.hbm.xml
has to be updated to include the custom subclass of VariableInstance.
For example, take a look at the following xml snippet in the file
org/jbpm/context/exe/jbpm.varmapping.xml.
<jbpm-type>
<matcher>
<bean class="org.jbpm.context.exe.matcher.ClassNameMatcher">
<field name="className"><string value="java.lang.Boolean" /></field>
</bean>
</matcher>
<converter class="org.jbpm.context.exe.converter.BooleanToStringConverter" />
<variable-instance class="org.jbpm.context.exe.variableinstance.StringInstance" />
</jbpm-type>This snippet specifies that all objects of type java.lang.Boolean have
to be converted with the converter BooleanToStringConverter and
that the resulting object (a String) will be stored in a variable instance object
of type StringInstance.
If no converter is specified as in
<jbpm-type>
<matcher>
<bean class="org.jbpm.context.exe.matcher.ClassNameMatcher">
<field name="className"><string value="java.lang.Long" /></field>
</bean>
</matcher>
<variable-instance class="org.jbpm.context.exe.variableinstance.LongInstance" />
</jbpm-type>that means that the Long objects that are put in the variables are just stored in a variable instance of type LongInstance without being converted.