As sketched in my story above, jBPM stores the SessionFactory in the "process-engine" WireContext (see ConfigurationImpl), but looks it up in the "transaction" WireContext. In my simple view of life, that explains why it doesn't work. So I've overridden the ConfigurationImpl.setHibernateTransactionFactory() to store the descriptor *also* in the "transaction" WireContext, like this:
ProcessEngine processEngine = new ConfigurationImpl() {
@Override
public ConfigurationImpl setHibernateSessionFactory(Object hibernateSessionFactory) {
ProvidedObjectDescriptor descriptor = new ProvidedObjectDescriptor(hibernateSessionFactory, true);
getProcessEngineWireContext().getWireDefinition().addDescriptor(descriptor);
getTransactionWireDefinition().addDescriptor(descriptor);
return this;
}
}.setResource("jbpm/jbpm.cfg.xml").setHibernateSessionFactory(hibernateSessionFactory).buildProcessEngine();
Now jBPM does use my injected SessionFactory (verified by doing the same debug session as described above; it's now obtaining the injected object wherever it's looking up a SessionFactory).
I'm not very familiar with the different jBPM WireContexts, so I hope a jBPM expert can take a look at my 'workaround', and say some smart stuff about whether this is can be considered a bug in the standard ConfigurationImpl, or whether I'm doing something dangerous here with nasty side-effects...
Thanks for your help,
Guido
ps: The problem described here: https://community.jboss.org/thread/150582 remains. I now have one SessionFactory, but it's still not possible to run my own stuff and jBPM stuff in one single transaction.