The system will automatically persist serializable classes as byte arrays.
I realize that, but I'd like to be able save the objects to an existing db schema; serialized classes won't due.
That is an easy task.
You must look the jbpm.varmapping.xml and you find something like that:
<!-- java.io.Serializable --> <jbpm-type> <matcher> <bean class="org.jbpm.context.exe.matcher.SerializableMatcher" /> </matcher> <converter class="org.jbpm.context.exe.converter.SerializableToByteArrayConverter" /> <variable-instance class="org.jbpm.context.exe.variableinstance.ByteArrayInstance" /> </jbpm-type>
This means that you have a matcher (that look the type of your class that you want to persist)
And then when your object match with a matcher you must convert it with a converter to a VariableInstance (more precisely a sub class that you define).
For an easy use I recommend you to look at the next pair of matchers and converters:
<!-- hibernatable long id types --> <jbpm-type> <matcher> <bean class="org.jbpm.context.exe.matcher.HibernateLongIdMatcher" /> </matcher> <variable-instance class="org.jbpm.context.exe.variableinstance.HibernateLongInstance" /> </jbpm-type> <!-- hibernatable string id types --> <jbpm-type> <matcher> <bean class="org.jbpm.context.exe.matcher.HibernateStringIdMatcher" /> </matcher> <variable-instance class="org.jbpm.context.exe.variableinstance.HibernateStringInstance" /> </jbpm-type>
This two matchers have the logic to search in your objects that have an hibernate mappings (defined in hbms files) but with a Long ID (HibernateLongInstance) or a
String ID (HibernateStringIdMatcher).
So, if your object does not have a Long or String ID, this two matchers wont work.
In this case you must implement your own matcher and your variable instance, following the same directions. (like HibernateStringInstance or HibernateLongInstance)
I hope it helps!!!
Personally I would not store domain specific objects in the jBPM table. I'd just store a reference to them (e.g. the primary key of it). The objects themselves I'd store them in their own database