Announcement Announcement Module
Collapse

Spring Modules forum decommissioned in favor of Spring Extensions

As the Spring Modules project has been replaced by the Spring Extensions (http://www.springsource.org/extensions) project, this forum has been decommissioned in favour of Spring Extensions one at:
http://forum.springsource.org/forumdisplay.php?f=44

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.

Cheers,
Costin Leau
SpringSource - http://www.SpringSource.com- Spring Training, Consulting, and Support - "From the Source"
http://twitter.com/costinl
See more
See less
jbpm getting started Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    I have tested only with jbpm 3.1.0. I'll let you know if I find anything.

    Comment


    • #17
      FYI, I've created an issue on JIRA: http://opensource.atlassian.com/proj...browse/MOD-136

      Comment


      • #18
        sorry if this is off topic now, but im following up on my post refering to the test folder earlier.

        I have had a look in the zip distribution & at the online cvs repository, but i cant find the testing folder with the example applicationContext.xml file.

        specifically, i am having trouble defining the hibernateConfiguration property of my org.springmodules.workflow.jbpm30.LocalJbpmSession FactoryBean bean (im using jbpm 3.0.2). I already have a org.springframework.orm.hibernate3.LocalSessionFac toryBean defined in my applicationContext.xml and i would like to use the configuration from this session factory. can you point me in the right direction regarding this?

        My bean def so far:

        Code:
        <bean id="hibernateSessionFactory" class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">
          <property name="mappingResources">
            <list>
              <value>...</value>
            </list>
          </property>
          <property name="hibernateProperties">
            <props>...</props>
          </property>
          <property name="dataSource">
            <ref bean="..."/>
          </property>
        </bean>
        
        <bean id="jbpmSessionFactoryBean" class="org.springmodules.workflow.jbpm30.LocalJbpmSessionFactoryBean">
        	<property name="hibernateSessionFactory" ref="hibernateSessionFactory"/>
        </bean>
        Thanks for any assistance forthcoming

        - tobes

        Comment


        • #19
          See this link from CVS: https://springmodules.dev.java.net/s...rkflow/jbpm30/
          I'll put up some documentation so it will be part of the next release. Clearly there is a need for it.

          Comment


          • #20
            New versions for process definitions

            Hi,

            I have also seen the problem with new versions of processes being created, this is due to the fact that the deployProcessDefinition method of GraphSession in JBPM 3.1.1 ensures that a new process definition with an updated version is saved if the process name already exists.

            I think I just need to come up with a method of flagging whether or not to deploy process definitions in the spring config file as currently my process definitions are specified in the Spring config file and as such are continuially re-deployed every time the server starts.

            Any useful suggestions would be most welcome

            Regards

            Scott

            Comment


            • #21
              Originally posted by Costin Leau
              See this link from CVS: https://springmodules.dev.java.net/s...rkflow/jbpm30/
              I'll put up some documentation so it will be part of the next release. Clearly there is a need for it.
              sweet as mustard, cheers.

              Comment


              • #22
                Have you tried the jbpm forums? I'm curios myself why a new updated version is saved on redeploy. I guess one way is to extend the method (if possible) and override the behavior - a bit risky but will get the job done.

                Comment


                • #23
                  Redeploy issue....solved???

                  Hi,

                  I have managed to get round this issue, but I think my solution is a bit hacky:

                  I extended the LocalJbpmConfigurationFactoryBean as shown below to have an additional property used to determine whether it should re-deploy a process definition if one of the same name already exists.

                  Code:
                  import java.io.InputStream;
                  import java.util.Arrays;
                  
                  import org.apache.log4j.Logger;
                  import org.hibernate.SessionFactory;
                  import org.jbpm.JbpmConfiguration;
                  import org.jbpm.JbpmContext;
                  import org.jbpm.configuration.ObjectFactory;
                  import org.jbpm.configuration.ObjectFactoryParser;
                  import org.jbpm.graph.def.ProcessDefinition;
                  import org.springframework.core.io.Resource;
                  import org.springmodules.workflow.jbpm31.LocalJbpmConfigurationFactoryBean;
                  
                  /**
                   * 
                   * @author Scott
                   */
                  public class CustomLocalJbpmConfigFactoryBean extends LocalJbpmConfigurationFactoryBean {
                  
                      private boolean redeployProcesses = false;
                      private static Logger logger = Logger.getLogger(CustomLocalJbpmConfigFactoryBean.class);
                  
                      private JbpmConfiguration jbpmConfiguration;
                  
                      /**
                       * @see org.springframework.beans.factory.FactoryBean#getObject()
                       */
                      public Object getObject() throws Exception {
                          return jbpmConfiguration;
                      }
                  
                      /**
                       * @see org.springframework.beans.factory.FactoryBean#getObjectType()
                       */
                      public Class getObjectType() {
                          return JbpmConfiguration.class;
                      }
                  
                      public boolean isRedeployProcesses() {
                          return redeployProcesses;
                      }
                      
                      public void setRedeployProcesses(boolean redeploy) {
                          redeployProcesses = redeploy;
                      }
                      /**
                       * @see org.springframework.beans.factory.InitializingBean#afterPropertiesSet()
                       */
                      public void afterPropertiesSet() throws Exception {
                          Resource configuration = this.getConfiguration();
                          ObjectFactory objectFactory = null;
                          SessionFactory sessionFactory = this.getSessionFactory();
                          ProcessDefinition[] processDefinitions = this.getProcessDefinitions();
                          String contextName = this.getContextName();
                          boolean createSchema = this.isCreateSchema();
                          
                          if (configuration == null && objectFactory == null)
                              throw new IllegalArgumentException("configuration or objectFactory property need to be not null");
                  
                          ObjectFactory jbpmObjectFactory;
                  
                          // 1. create the configuration from the file
                          if (configuration != null) {
                              logger.info("creating JbpmConfiguration from resource " + configuration.getDescription());
                              InputStream stream = configuration.getInputStream();
                              jbpmObjectFactory = ObjectFactoryParser.parseInputStream(stream);
                              stream.close();
                          }
                          else
                              jbpmObjectFactory = objectFactory;
                  
                          jbpmConfiguration = new JbpmConfiguration(jbpmObjectFactory);
                  
                          // 2. inject the HB session factory if it is the case
                          if (sessionFactory != null) {
                              logger.info("using given Hibernate session factory");
                              JbpmContext context = jbpmConfiguration.createJbpmContext(contextName);
                              try {
                                  context.setSessionFactory(sessionFactory);
                              }
                              finally {
                                  context.close();
                              }
                          }
                  
                          // 3. execute persistence operations
                          if (createSchema) {
                              logger.info("creating schema");
                              jbpmConfiguration.createSchema(contextName);
                          }
                          
                          if (processDefinitions != null && processDefinitions.length > 0) {
                              //TODO: replace with another faster utility
                              String toString = Arrays.asList(processDefinitions).toString();
                              logger.info("deploying process definitions:" + toString);
                              JbpmContext context = jbpmConfiguration.createJbpmContext(contextName);
                              try {
                                  for (int i = 0; i < processDefinitions.length; i++) {
                                      // Only deploy process that don't already exist or if the redeploy flag is set.
                                      String name = processDefinitions[i].getName();
                                      ProcessDefinition def = context.getGraphSession().findLatestProcessDefinition(name);
                                      if (def == null || redeployProcesses) {
                                          context.deployProcessDefinition(processDefinitions[i]);
                                      }
                                      else {
                                          logger.info("Skipping definition : " + def.getName());
                                          
                                          // Replace the process definition entry with the one loaded by the context.
                                          processDefinitions[i] = def;
                                      }
                                  }
                              }
                              finally {
                                  context.close();
                              }
                          }
                      }
                  
                  }
                  I then had issues with persisting new Process instances as the JbmpTemplate was using the ProcessDefinition retrieved from the ProcessDefinitionFactoryBean so what I ended up doing was setting the ProcessDefinition property of the template manually by looking up the process definition latest version using the name before using the template.

                  Can anyone come up with a more elegant solution to this?

                  Regards,

                  Scott

                  PS: Is this the correct thread for this, sorry if I'm posting in the wrong place.

                  Comment


                  • #24
                    I don't think there is any easy way out. The code is also dependent on jbpm 3.1.1 (the issue from what I understand doesn't occur on 3.1.0).
                    Have you discussed the new version issue on jbpm forums?

                    Comment


                    • #25
                      Originally posted by Costin Leau
                      I don't think there is any easy way out. The code is also dependent on jbpm 3.1.1 (the issue from what I understand doesn't occur on 3.1.0).
                      Have you discussed the new version issue on jbpm forums?
                      Hi Costin,

                      Looking at the jBPM forums it seems like versioning is a topic still under discussion, but the current implementation is working as intended (unfortunately for me). Looks like I'll just have to use my hacked up version until such times as the issue is resolved.

                      Regards,

                      Scott

                      Comment


                      • #26
                        Originally posted by scott_mathieson
                        Hi Costin,

                        Looking at the jBPM forums it seems like versioning is a topic still under discussion, but the current implementation is working as intended (unfortunately for me). Looks like I'll just have to use my hacked up version until such times as the issue is resolved.

                        Regards,

                        Scott
                        Taking a closer look at jBPM source code it may be that jBPM is indeed doing the "right thing" for the time being.

                        If you think about process definitions as persistent objects, it makes sense. Every time you call deployProcessDefinition, you get a new DB row. And because that row persists across restarts, you don't need to deploy the process again unless it changes. So maybe Spring xml config isn't the right place for the process defs in the first place, unless you're dropping the db on every restart.

                        Now, it would be *nice* if deployProcessDefinition did some kind of deep-compare to see if the process has changed, and redeploy only if necessary. But unnessential.

                        Comment


                        • #27
                          The new Spring Modules 0.4 documents jBPM usage. See https://springmodules.dev.java.net/d...single/#jbpm31.

                          Comment


                          • #28
                            Now, it would be *nice* if deployProcessDefinition did some kind of deep-compare to see if the process has changed, and redeploy only if necessary. But unnessential.
                            That could be achieved by providing some sort of process signature or version which can indicate if an update was made or not.
                            Just an idea...

                            Comment


                            • #29
                              Solution to Redeploying Process Definitions?

                              Hello all -

                              I would like to determine if a solution has been found to resolve redeploying the process definition on server start-up. I have this issue and have been following this thread to find a resolution.

                              Costin created a JIRA issue, but the proposed resolution doesn't make sense to me...

                              http://opensource.atlassian.com/proj...browse/MOD-136

                              Also, overriding the JbpmTemplate to check for existing process definitions doesn't appear to be a graceful solution to this. Any advise you can offer is greatly appreciated.

                              Kind Regards,
                              R. Alcazar

                              Comment


                              • #30
                                The JIRA issue is marked as won't fix - basically there isn't any clean solution that the integration module can provide. As you've seen from the discussions and links on this threads there are various approaches, the easiest one being to create the schema only once and then work with the db without redeploying the process definition.
                                AFAIK, the JBPM has no means of verifying if a definition has been deployed or doing a merge/resolving the error so there isn't an official way to deal with it.

                                Comment

                                Working...
                                X