[jboss-user] [JBoss jBPM] - Re: org.hibernate.HibernateException: null index column for

clandestino_bgd do-not-reply at jboss.com
Tue Jul 29 11:30:11 EDT 2008

Hello Ronald, thanks for the reply.
I managed to resolve the problem. 
I am answering to your questions below, in case somebody else is also trying to use JBPM inside Appfuse.
 anonymous wrote : 
  | - do you use spring jBPM template? if so, ditch it (not spring, just this template, it's officially only for 3.1.x afaik) 
Yes, I do. Actually I extend JbpmTemplate from spring modules and it works very well, so for now I do not plan to ditch it.
anonymous wrote : 
  | - Do both the junit and tomcat use spring? 
Yes. I am extending AbstractTransactionalDataSourceSpringContextTests in my test classes (one for each process definition). Every method ends with explicit setComplete() call in order to do actual insert in DB. I need that for async exec and callbacks.
anonymous wrote : 
  | - Same jbpm config? (not e.g. one without and one with transactions configured) 
Yes, the same jbpmConfig, defined in spring applicationContext.xml (slightly modified spring-modules LocalJbpmConfigurationFactoryBean), loaded by StartupListener and Base Junit test class.
anonymous wrote : 
  | - same transactionmanager?
  | - same transactionmanager config? 
Well, this was the trick. Transactions are declared through AOP originally in appfuse, and I moved my WorkflowManager in another module. That caused all JBPM calls to be outside the transaction.  In Junit test the transactions are provided by Spring base Junit test class, so there were no problems.
Btw, I defined a custom DbPersistenceServicefactory, since I had to extend GraphSession and TaskMgmtSession.

  |  <service name="persistence">
  |       <factory>
  |         <bean class="gleam.executive.workflow.core.JbpmDbPersistenceServiceFactory">
  |           <field name="isTransactionEnabled"><false /></field>
  |         </bean>
  |       </factory>
  |     </service>
This seems to work well.

anonymous wrote : 
  | Does this mean you have very few big classes that do a lot of work?
No, it means that my Junit test are spring dependent. Also, they include some utility classes, since they perform complete process definition tests according to all possible scenarios.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4167366#4167366

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4167366

More information about the jboss-user mailing list