In ODE the message exchange id (mex id) is a string used as the unique id of a the MessageExchangeDao. Depending on the DAO implementation this information might be persisted in database.
In ODE 1.X, for the Hibernate implementation, the mex id is actually a long converted into a string in org...daohib...MessageExchangeDaoImpl#getMessageExchangeId. This id is also the primary key of the underlying table BPEL_MESSAGE_EXCHANGE and is generated by the database.
But in ODE trunk, the mex id is now generated by the caller of BpelDAOConnection#createMessageExchange and is a 128-bit Global Unique Identifier, which is not convertible into a long. So, in trunk, BPEL_MESSAGE_EXCHANGE has an additional column MEXID (string) to save the guid.
The NPE reported here is due to a bug in org.apache.ode.daohib.bpel.MessageExchangeDaoImpl#getMessageExchangeId. Actually the current implementation still returns the database id (the long) instead of the mex id (the guid). Actually the MessageExchange is cached by org.apache.ode.bpel.engine.MyRoleMessageExchangeCache base on the mex id.
When the reference is put into the cache, the mex id come from the freshly created MyRoleMessageExchangeImpl instance with the proper GUID. When the reply is received the org.apache.ode.daohib.bpel.MessageExchangeDaoImpl (the buggy one) is loaded from the database based on the GUID. And the look up call from the cache uses a wrong id and cannot retrieved the MyRoleMessageExchangeImpl instance with the waiting future. In that case the cache creates and returns a new instance with null futur. Hence the NPE.
This issue does not happen with JPA because the mex id (the guid) is also the primary key.
To use the trunk on an existing 1.x hibernate database, a migration script would have to be ran previously to populate BPEL_MESSAGE_EXCHANGE.MEXID with BPEL_MESSAGE_EXCHANGE.ID.