Announcement Announcement Module

Spring Modules forum decommissioned in favor of Spring Extensions

As the Spring Modules project has been replaced by the Spring Extensions ( project, this forum has been decommissioned in favour of Spring Extensions one at:

Please see the Spring Extensions home page for a complete list of current projects in Java, .NET and ActionScript. You can also propose one if you want.

Costin Leau
SpringSource - Spring Training, Consulting, and Support - "From the Source"
See more
See less
Two problems occurred when integrating spring with jbpm Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Two problems occurred when integrating spring with jbpm

    Because of increasing scalability,our web server and app server exist on the different machines.We use the ejb to communicate.When not integrating with jbpm,no error occur.But when integrating spring with jbpm,we faced two problems.
    1)Because using ejb,ejb will make multiple instance,each creates its own bean factory.when using jbpm,it always throws exception "a beanFactoryReference already exists for key".Jbpm module allows only one bean factory exist.Now exist multiple bean factory,so exception is throwed.

    I tried to use SingletonBeanFactoryLocator to make only one bean factory even if multiple ejb instance.Something apparently run well.

    But when ejb throws exception or finishes work,spring will descrease the count of bean factory reference.When count is 0,Spring will destory the bean factory.But it does not destory the jbpm's JbpmFactoryLocator. Someone call ejb,jbpm will throw "a beanFactoryReference already exists for key".

    So I extend the SingletonBeanFactoryLocator ,when reference count descrease to 0,I will destory JbpmFactoryLocator.And improve the efficiency,when getInstance of SingletonBeanFactoryLocator, I increase the count number.This makes not loading bean factory and jbpm repeatedly.So even if nobody call ejb,bean factory reference will also be 1.

    But I dont know this is the best solution?

    2)In the configuration file,when using jbpmConfiguration bean
    <bean id="jbpmConfiguration"
    		<property name="sessionFactory" ref="hibernateSessionFactory" />
    		<property name="configuration" value="classpath:jbpm.cfg.xml" />
    		<property name="processDefinitions">
    				<ref local="simpleWorkflow" />
    I must provide the processDefinitions property.That means when start the server,it will redeploy again.Deploy waste too much time.When I delete it from configuration file,always throws exception.But i dont know how to solve it.

  • #2
    Hi bobby_sz,

    1) you make a good point. I already have a report on this issue and I'll try to address it ASAP and include in the next release. The problem occurs since some static fields are used in order to bridge with JBPM but as you pointed out, the cleanup lets the static fields uninitialized. I'll try to find a workaround so restarts are possible.

    2) It is the simpleWorkflow processDefinition or the jbpm.cfg.xml configuration that takes too much time? Some time has to be spent on reading the information from the database - if you skip this step you can't persist your bpm to the database.
    What step is optional/redundant in this case?


    • #3
      Thanks for your reply,costin.

      In LocalJbpmConfigurationFactoryBean,when set processDefinitions property,it will deploy process definition.That means jbpm will redeploy again when restart the server.But process definition is same,I do not want to do that.

      When I don't set processDefinitions property,jbpm will not redeploy unless deploy it manually,but some errors occur.I do not know what's wrong.


      • #4

        Exception just like that:
        17:44:20,625 ERROR [ApplicationControllerBean] Application controller exception:[null]/[1165311851531113]:org.springframework
        .dao.InvalidDataAccessApiUsageException: org.jbpm.graph.def.ProcessDefinition; nested exception is org.hibernate.TransientObj
        ectException: org.jbpm.graph.def.ProcessDefinition
        Caused by: org.hibernate.TransientObjectException: org.jbpm.graph.def.ProcessDefinition
                at org.hibernate.engine.ForeignKeys.getEntityIdentifierIfNotUnsaved(
                at org.hibernate.type.EntityType.getIdentifier(
                at org.hibernate.type.ManyToOneType.isDirty(
                at org.hibernate.type.TypeFactory.findDirty(
                at org.hibernate.persister.entity.AbstractEntityPersister.findDirty(
                at org.hibernate.event.def.DefaultFlushEntityEventListener.dirtyCheck(
                at org.hibernate.event.def.DefaultFlushEntityEventListener.isUpdateNecessary(
                at org.hibernate.event.def.DefaultFlushEntityEventListener.onFlushEntity(
                at org.hibernate.event.def.AbstractFlushingEventListener.flushEntities(
                at org.hibernate.event.def.AbstractFlushingEventListener.flushEverythingToExecutions(AbstractFlushingEventListener.ja
                at org.hibernate.event.def.DefaultFlushEventListener.onFlush(
                at org.hibernate.impl.SessionImpl.flush(
                at org.hibernate.impl.SessionImpl.managedFlush(
                at org.hibernate.transaction.JDBCTransaction.commit(
                at org.springframework.orm.hibernate3.HibernateTransactionManager.doCommit(
                at org.springframework.transaction.interceptor.TransactionAspectSupport.commitTransactionAfterReturning(TransactionAs
                at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(
                at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(
                at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(
                at $Proxy60.perform(Unknown Source)
                at sun.reflect.GeneratedMethodAccessor236.invoke(Unknown Source)
                at sun.reflect.DelegatingMethodAccessorImpl.invoke(
                at java.lang.reflect.Method.invoke(
                at org.jboss.invocation.Invocation.performCall(
                at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(
                at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(
                at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(
                at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(
                at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(
                at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(
                at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(
                at org.jboss.ejb.plugins.SecurityInterceptor.invoke(
                at org.jboss.ejb.plugins.LogInterceptor.invoke(
                at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(
                at org.jboss.ejb.SessionContainer.internalInvoke(
                at org.jboss.ejb.Container.invoke(
                at sun.reflect.GeneratedMethodAccessor195.invoke(Unknown Source)
                at sun.reflect.DelegatingMethodAccessorImpl.invoke(
                at java.lang.reflect.Method.invoke(
                at org.jboss.invocation.local.LocalInvoker$MBeanServerAction.invoke(
                at org.jboss.invocation.local.LocalInvoker.invoke(
                at org.jboss.invocation.InvokerInterceptor.invokeLocal(
                at org.jboss.invocation.InvokerInterceptor.invoke(
                at org.jboss.proxy.TransactionInterceptor.invoke(
                at org.jboss.proxy.SecurityInterceptor.invoke(
                at org.jboss.proxy.ejb.StatelessSessionInterceptor.invoke(
                at org.jboss.proxy.ClientContainer.invoke(
                at $Proxy55.handleRequest(Unknown Source)
                at sun.reflect.GeneratedMethodAccessor235.invoke(Unknown Source)
                at sun.reflect.DelegatingMethodAccessorImpl.invoke(
                at java.lang.reflect.Method.invoke(
                at org.springframework.remoting.rmi.RmiClientInterceptorUtils.doInvoke(
                at org.springframework.ejb.access.SimpleRemoteSlsbInvokerInterceptor.doInvoke(
                at org.springframework.ejb.access.AbstractRemoteSlsbInvokerInterceptor.invoke(AbstractRemoteSlsbInvokerInterceptor.ja
                at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(
                at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(
                at $Proxy57.handleRequest(Unknown Source)
                at com.sinosafe.huafa.web.controller.WebControllerTemplate.dispatchAction(
                at com.sinosafe.huafa.web.controller.WebControllerTemplate.execute(
                at com.sinosafe.claim.autoclaim.web.controller.acceptcase.ReportAcceptController.onSubmit(
                at org.springframework.web.servlet.mvc.SimpleFormController.processFormSubmission(
                at org.springframework.web.servlet.mvc.AbstractFormController.handleRequestInternal(
                at org.springframework.web.servlet.mvc.Abstr


        • #5
          Seems that Hibernate doesn't know about your process definition. This has been reported before but there is not much Spring Modules can do here - I'm not sure how things are in JBPM but AFAIK, there is no API to verify if a process has been deployed or not. Spring Modules simply calls JBPM API which in turn does the hard redeploy of the mapping.
          If anybody knows a workaround, please shout!


          • #6
            Thanks any way.