Discovered what the issue is here. A serializable-value is handled differently than any other variables, since it can be altered in-memory. They are, when the context closes, checked for modification and flushed to the database, without an explicit "setVariable()" command. The code involved:
public void flush() {
// this first check verifies if the variable value was not overwritten with another object
if (deserializedObject==variableInstanceEntity.getCachedValue()) {
byte[] bytes = SerializableType.serialize(deserializedObject, variableInstanceEntity);
if (!Arrays.equals(originalBytes, bytes)) {
variableInstanceEntity
.getByteArrayValue()
.setBytes(bytes);
}
}
}
This works as expected, but down not update the historic detail-value, because there is no explicit "setVariable()" command called, so no historic detail can be recorded. If you would have an additional (service/receive) tasks after the task, you would see that the RUNTIME variable is indeed altered. Workaround for this is to add an additional service-task (or script-task) after the userTask, that does nothing more than call "execution.setVariable(execution.getVariable("stInfo")".
. You're missing a closing bracket!
