3 Replies Latest reply on Jan 3, 2008 11:55 AM by apdo

    jbpm-console + versioned seam backing bean

      Jbpm-console seam to be a very good starting point if we need to write an application that allow user to deploy is own defined processes.

      In order to package the jbpm-console with additional feature specific to our customers, I plan to benefit for the ease of development that seam allows. I have written some small seam application. Then, I try to integrate the seam jar and required configuration in web.xml, faces-config.xml seam.properties...

      Since then, the jbpm-console seems to work fine (I am able to initiated process, complete task ...). However, I keep getting the stack trace, which will follow, for almost every action I perform in the jbpm-console. Do you have an idea how to fix this?

      The stack trace is something I have tried to fix. However, since the application seems to work fine, I have tried to use backing bean. I still have some problem (probably due to my short experience with seam) but I have been able to use the websale demo and add a call to a backing bean in the form.create.xhtml file. For now I have add to put my backing bean directly into the WEB-INF/classes/… folder. Does anybody have tried to have the seam backing been versioned in the par file like the action handler and forms are?

      thanks in advance for you precious help,

      An Phong Do


      I have added the stack trace add content of configuration files here.


      07-12-05 08:17:03,578 DEBUG [org.jbpm.persistence.db.DbPersistenceService] rolling back hibernate transaction
      2007-12-05 08:17:03,578 DEBUG [org.hibernate.transaction.JDBCTransaction] rollback
      2007-12-05 08:17:03,578 DEBUG [org.jbpm.persistence.db.DbPersistenceService] closing hibernate session
      2007-12-05 08:17:03,578 ERROR [org.jbpm.svc.Services] problem closing service 'persistence'
      org.jbpm.persistence.JbpmPersistenceException: hibernate commit failed
      at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:219)
      at org.jbpm.svc.Services.close(Services.java:225)
      at org.jbpm.JbpmContext.close(JbpmContext.java:139)
      at org.jbpm.jsf.core.phase.JbpmPhaseListener.closeContext(JbpmPhaseListener.java:94)
      at org.jbpm.jsf.core.phase.JbpmPhaseListener.afterPhase(JbpmPhaseListener.java:45)
      at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:280)
      at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:144)
      at javax.faces.webapp.FacesServlet.service(FacesServlet.java:245)
      at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
      at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
      at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
      at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:58)
      at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
      at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:85)
      at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
      at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
      at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
      at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:44)
      at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
      at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
      at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
      at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
      at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
      at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
      at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
      at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
      at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
      at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:179)
      at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:524)
      at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:84)
      at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
      at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
      at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
      at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
      at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:262)
      at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
      at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
      at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:446)
      at java.lang.Thread.run(Thread.java:619)
      Caused by: org.hibernate.TransactionException: JDBC commit failed
      at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:130)
      at org.jbpm.persistence.db.DbPersistenceService.commit(DbPersistenceService.java:256)
      at org.jbpm.persistence.db.DbPersistenceService.close(DbPersistenceService.java:214)
      ... 38 more
      Caused by: java.sql.SQLException: You cannot commit during a managed transaction!
      at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnection.jdbcCommit(BaseWrapperManagedConnection.java:543)
      at org.jboss.resource.adapter.jdbc.WrappedConnection.commit(WrappedConnection.java:334)
      at org.hibernate.transaction.JDBCTransaction.commitAndResetAutoCommit(JDBCTransaction.java:139)
      at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:115)
      ... 40 more




      Web.xml
      <?xml version="1.0" encoding="UTF-8"?>
      <web-app xmlns="http://java.sun.com/xml/ns/javaee"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
      version="2.5">

      <!-- Seam -->


      <listener-class>org.jboss.seam.servlet.SeamListener</listener-class>



      <servlet-name>Seam Resource Servlet</servlet-name>
      <servlet-class>org.jboss.seam.servlet.SeamResourceServlet</servlet-class>


      <servlet-mapping>
      <servlet-name>Seam Resource Servlet</servlet-name>
      <url-pattern>/seam/resource/*</url-pattern>
      </servlet-mapping>


      <filter-name>Seam Filter</filter-name>
      <filter-class>org.jboss.seam.servlet.SeamFilter</filter-class>


      <filter-mapping>
      <filter-name>Seam Filter</filter-name>
      <url-pattern>/*</url-pattern>
      </filter-mapping>

      <context-param>
      <param-name>javax.faces.DEFAULT_SUFFIX</param-name>
      <param-value>.xhtml</param-value>
      </context-param>

      <context-param>
      <param-name>com.sun.faces.verifyObjects</param-name>
      <param-value>true</param-value>
      </context-param>

      <context-param>
      <param-name>facelets.SKIP_COMMENTS</param-name>
      <param-value>true</param-value>
      </context-param>

      <!-- Faces Servlet -->


      <servlet-name>Faces Servlet</servlet-name>
      <servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
      <load-on-startup>1</load-on-startup>


      <servlet-mapping>
      <servlet-name>Faces Servlet</servlet-name>
      <url-pattern>*.seam</url-pattern>
      </servlet-mapping>

      <session-config>
      <session-timeout>10</session-timeout>
      </session-config>
      </web-app>



      Faces-config.xml
      <?xml version='1.0' encoding='UTF-8'?>
      <faces-config xmlns="http://java.sun.com/xml/ns/javaee"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facesconfig_1_2.xsd"
      version="1.2">



      <locale-config>
      <default-locale>en</default-locale>
      </locale-config>

      <!--
      Use Facelets as the primary view handler. Since we have bookmarkable URLs,
      add Gravel's query preserving view handler to the list.
      -->
      <view-handler>com.sun.facelets.FaceletViewHandler</view-handler>




      <phase-listener>org.jboss.seam.jsf.SeamPhaseListener</phase-listener>

      </faces-config>

      Components.xml
      <components xmlns="http://jboss.com/products/seam/components"
      xmlns:core="http://jboss.com/products/seam/core">


      Seam.properties is empty


        • 1. Re: jbpm-console + versioned seam backing bean

          I figure out that for my needs, with all the Seam features, I is easier for me to write my own application instead of trying to adapt the bpm-console.

          I have started from the seam-todo example. I have added a xhtml form with field to fill for the todo task. This form use a backing bean and it work fine.

          From there I have remove the todo process definition from the todo example and create a xhtml page that allows me to deploy process definition.

          I have deploy a first version of my todo process definition. this process definition include the processdefinition.xml and the backing bean in the par file
          I have start the process and it use the backing bean that come from the par file!

          I have deploy a second version of my todo process definition. this process is identical to the previous version except that I have modify the string that is printed from one of the backing bean method. I start a process of this second process definition version.
          I realize that both the process of the version one and the process of the version two are using the first version of the backing bean.


          Like it is possible to do in the bpm console, I want my user to be able to deploy in my application new process and new process version of already deployed processes.

          for a process definition, the versionning is supported for:
          the process definition (xml file)
          the action handler
          and the task xhtml form (there is a good example on how to do this in the bpm-console)

          however, a xhtml form to be fully functional must need backing bean.


          1. Is this supported and I am doing something wrong in my test to use backing bean?

          If it is not supported, is it a planned feature? I will look into the code but I don't think I could easily had this feature myself.

          2. An alternative would be to have a ear for every version of the process definition. This ear will include the backing bean for a specific version of the process definition. This should work fine however, following my limited testing on this, the startup of jboss is significantly longer if I deploy a lot of ear.
          What is your though about this alternative?


          An Phong Do
          solabs.com

          • 2. Re: jbpm-console + versioned seam backing bean
            kukeltje

            First I think you are right in stating that for more complex ui things it is better to write your own app instead of adaptiing the jbpm console. The latter is nice for RAD/Demo purposes

            1) This is not realy supported when just using seam. And afaik not on a todo list. It's not only difficult for you to add, but difficult in general

            2) Correct, but I always wonder how the url's of the app(s) will looke like then. Maybe some generic webapp is needed as well that just redirects to the correct one without it being visible in the url. No idea how to solve this though. I'd be very interested in this as well.

            • 3. Re: versioned seam backing bean

              Thanks for your reply.


              Ronald said: "This is not really supported when just using seam".
              Do you means there is mechanism that allowed versioned backing bean that is not using "just" seam? Is these methods documented? If I understand correctly, it will require custom classloading at the JSF or seam layer.

              For now, I don't expect to have this versioned backing bean mechanism working for me. For this reason, I will most probably look further in the direction of the one ear per processes version. I planned to have all the processes access from a main ear from where links will be available to the process instance that will be deploy in other ears. I am only scarred a little bit about future performance issues.


              I never try it yet but I already read about a single sign on (SSO) library that can be use by multiple web application on jboss. I will most probably try it to make all the application required the same authentication mechanism.


              An Phong Do