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
a beanFactoryReference already exists for key jbpmConfiguration Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • a beanFactoryReference already exists for key jbpmConfiguration

    I see a few people are having this problem, but it is not pointing me in any direction. I have set up Jbpm per the docs and have a workflowDAO object that takes the JbpmTemplate via a DI method. This DAO is then used by a service level object which is injected into various Spring MVC controllers. Unfortunately when the application context is almost done starting up in my tomcat server, I get the error:
    "a beanFactoryReference already exists for key jbpmConfiguration"

    I have been running jBPM 3.0 for a while and now am migrating to 3.1, but this is keeping me from running my local dev server properly. Any pointers are greatly appreciated. Below are snippets from my springapp-*.xml files.

    Thanks for any input,
    Julian

    Spring 2.0.2
    Jbpm 3.1.4
    Spring-modules 0.7
    Java 5
    Tomcat 5.5.x


    Root springapp file (has import statements to other springapp-* files for other beans:
    Code:
    ...
        <bean id="hibernateSessionFactory" class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">
            <property name="dataSource">
                <ref bean="workflowDataSource"/>
            </property>
            <property name="mappingLocations">
                <value>classpath*:/org/jbpm/**/*.hbm.xml</value>
            </property>
            <property name="hibernateProperties">
                <props>
                    <prop key="hibernate.dialect">org.hibernate.dialect.PostgreSQLDialect</prop>
                    <prop key="hibernate.show_sql">false</prop>
                    <prop key="hibernate.cache.provider_class">org.hibernate.cache.HashtableCacheProvider</prop>
                </props>
            </property>
            <property name="schemaUpdate" value="true"/>
        </bean>
        
        <!-- jBPM configuration -->
        <bean id="jbpmConfiguration" 
            class="org.springmodules.workflow.jbpm31.LocalJbpmConfigurationFactoryBean">
          <property name="sessionFactory" ref="hibernateSessionFactory"/>
          <property name="configuration" value="classpath:jbpm.cfg.xml"/>
          <property name="createSchema" value="true"/>
        </bean>
        
        <!-- jBPM template -->
        <bean id="jbpmTemplate" class="org.springmodules.workflow.jbpm31.JbpmTemplate">
            <constructor-arg index="0" ref="jbpmConfiguration"/>
        </bean>
         
        <bean id="transactionManager" class="org.springframework.orm.hibernate3.HibernateTransactionManager">
            <property name="sessionFactory" ref="hibernateSessionFactory"/>
        </bean>
    
        <bean id="manager" class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean">
             <property name="transactionManager" ref="transactionManager"/>
            <property name="target" ref="jbpmTemplate"/>
            <property name="transactionAttributes">
                   <props>
                     <prop key="*">PROPAGATION_REQUIRED, ISOLATION_READ_COMMITTED</prop>
                  </props>
               </property>
        </bean>
    ...
    springapp-data-access.xml
    Code:
    ...
        <bean id="workflowDataSource" class="org.springframework.jndi.JndiObjectFactoryBean">
            <property name="jndiName" value="java:comp/env/jdbc/workflow"/>
        </bean>
        
        <bean id="workflowDAO" class="com.ethidium.wEMR.dao.WorkflowDAO">
            <property name="jbpmTemplate" ref="jbpmTemplate"/>
        </bean>
    ...
    And again various service level beans and MVC controller's use the workflowDAO via DI methods.

  • #2
    I found that Spring was loading twice in my servlet container b/c of the spring servlet and the ContextLoaderListener for spring were both loading the application context. I reconfigured my use of the import statements in the spring*.xml files and my web.xml, and now it starts fine...just a few more kinks and it should be running.

    Comment


    • #3
      Same problem - a beanFactoryReference already exists for key jbpmConfiguration

      Hi Julian,

      I am getting the same error. Can you please elaborate this "I reconfigured my use of the import statements in the spring*.xml files and my web.xml" ?

      FYI, I have not written any classes for Workflow so far, I am just loading a Simple workflow at this point in time.

      Please find attached my web.xml and Spring xml.

      Thanks in Advance
      Shashank

      Comment


      • #4
        Well unless you are supporting another Webapp running in the same servlet context (e.g. legacy JSP pages or some other MVC framework like Struts *that will utilize the spring beans* EDIT), there is no need to use the contextLoaderListener. However since you have that configured and the Spring servlet, I am assuming you do. This config results in both the listener and the servlet loading your application context (from what I have observed). The end result is the jbpmConfiguration being created the first time by the ContextLoaderListener, and then again when your Spring servlet starts (look at your logs you might see certain beans being initiated twice b/c the application context gets started twice). Once the factory realizes the bean already exists, it will throw an error. I am not aware of all the internals, but it seems that Costin (the jbpm modules author we are grateful of) wrote the factory to be inline with many of the static runtime objects that jBPM relies upon. In order to get around this problem, you need to break down your springapp-dispatcher.xml file. My suggestion is to take all your MVC beans and keep them in the springapp-dispatcher.xml file (which the Spring servlet will load) and the rest of your beans (e.g. service level object/transaction managers/jbpm/etc) into another springapp-XXXX.xml file (make sure XXX does not equal "servlet"). Then change the contextConfigLocation mapping in web.xml to point to the springapp-XXXX.xml file:
        Code:
            <context-param>
                <param-name>contextConfigLocation</param-name>
                <param-value>
                    /WEB-INF/springapp-XXXX.xml
                </param-value>
            </context-param>
        Again, the ContextLoaderListener will load springapp-XXXX.xml first, and then the Spring dispatch servlet will load the springapp-dispatcher.xml file. This all boils down to loading sequences and classpath loaders:

        From http://www.springframework.org/docs/reference/mvc.html
        The framework will, on initialization of a DispatcherServlet, look for a file named [servlet-name]-servlet.xml in the WEB-INF directory of your web application and create the beans defined there (overriding the definitions of any beans defined with the same name in the global scope).
        All the beans in your springapp-XXX.xml file will be visible to the springapp-dispatcher.xml file. I am not sure about vice versa though, so be mindful of where you put which beans. Finally, if Spring is having problems finding springapp-dispatcher.xml, try springapp-servlet.xml. That worked better for me.

        hth,
        Julian
        Last edited by julian; Mar 13th, 2007, 11:59 AM.

        Comment


        • #5
          Thanks for the nice reply (and the nice words) Julian.
          Julian is correct so I'll only add that since jbpm uses a lot of statics, one initialized, the 'connection'/reference to the Spring application context is done through static fields. this is problematic since on reload or another jbpm instance, the static can be overridden by accident or on purpose.
          In your case is by accident and that's why you have the message - basically make sure that you load only one a jpbm FactoryBean pointing to the same application context - note that you can have as many as you like but the configuration has to be a bit different.
          I suggest to read again the documentation carefully and follow the advices above.

          Comment


          • #6
            It worked!

            Thanks for the detailed and prompt reply.

            I do not need any other Webapp running in the same servlet context, so I removed the contextLoaderListener entry from my web.xml and things are running fine now.

            Regards
            Shashank

            Comment


            • #7
              similar but not same problem

              Hi there,

              i am getting the same errormessage and from what i have read, the problem is that the applicationContext is getting loaded several times. But because i'm running several JUnit tests, this is actually what i want.

              In my Project, each TestCase-Class has its own applicationContext:
              MyFirstTest.java [JUnit Test]
              MyFirstTest-Context.xml [Spring App.Context]

              MySecondTest.java [JUnit Test]
              MySecondTest-Context.xml [Spring App.Context]

              ...aso.

              If I run the tests in isolation, everything works fine, but when i build a TestSuite including and executing all Test-Classes in a row i get the above Error:
              a beanFactoryReference already exists for key jbpmConfiguration
              Actually the error only occurs if i have two (or more) TestClasses in my Suite that include a jbpmConfiguration in their applicationContext.

              So i guess the jbpmConfiguration "survives" the loading of a new Test-Context. Why is this? Is there a workaround, allowing me to run all tests in a TestSuite, with different applicationContexts for each TestClass?

              The Issue is also mentioned in the jBPM-Forums:
              jboss.com/index.html?module=bb&op=viewtopic&p=4145969#414596 9
              There is no solution, but they suggest bringing it up here, so i did.

              Best Regards,
              Fredde

              Comment


              • #8
                Seems as if this JIRA issue is related:
                jira.springframework.org/browse/MOD-266
                Problem was solved for springmodules v0.7, but other usecases remain problematic.

                Any chance the issue will be reopened?

                Still looking for a workaround

                Regards,
                Fred.

                Comment

                Working...
                X