1 2 Previous Next 18 Replies Latest reply on Jul 20, 2006 6:52 PM by Luca Faggioli

    Web console failing

    Brad O'Hearne Newbie

      I have deployed the jbpm.sar and jbpm.war built from the jbpm 3.1.1 starter's kit (along with required libraries to my best knowledge) into JBoss 4.0.4. JBoss starts up without any errors. When I access the webapp at http://localhost:8080/jbpm, I receive the normal home page fine, without any errors. However, if I try to click on the "Home", "Administration", or "Monitoring" links on the left hand side, I get a 500 response, with an ugly stack trace. Checking in the jboss log, I see the following error:

      2006-07-12 11:40:18,078 ERROR [javax.faces.webapp.UIComponentTag] Faces context not found. getResponseWriter will fail. Check if the FacesServlet has been initialized at all in your web.xml.
      2006-07-12 11:40:18,125 DEBUG [org.jbpm.JbpmContext] closing JbpmContext
      2006-07-12 11:40:18,125 DEBUG [org.jbpm.svc.Services] closing service 'authentication': org.jbpm.security.authentication.DefaultAuthenticationService@723c42
      2006-07-12 11:40:18,125 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/jbpm].[jsp]] Servlet.service() for servlet jsp threw exception
      java.lang.NullPointerException
       at javax.faces.webapp.UIComponentTag.setupResponseWriter(UIComponentTag.java:615)
       at javax.faces.webapp.UIComponentTag.doStartTag(UIComponentTag.java:217)
       at org.apache.myfaces.taglib.core.ViewTag.doStartTag(ViewTag.java:71)
       at org.apache.jsp.home_jsp._jspx_meth_f_view_0(home_jsp.java:102)
       at org.apache.jsp.home_jsp._jspService(home_jsp.java:76)
       at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
       at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
       at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:332)
       at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
       at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
       at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
       at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
       at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
       at org.jbpm.webapp.filter.AuthenticationFilter.doFilter(AuthenticationFilter.java:55)
       at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
       at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
       at org.jbpm.web.JbpmContextFilter.doFilter(JbpmContextFilter.java:83)
       at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
       at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
       at org.jbpm.webapp.filter.LogFilter.doFilter(LogFilter.java:59)
       at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
       at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
       at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
       at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
       at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
       at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
       at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
       at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
       at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
       at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
       at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
       at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
       at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
       at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
       at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
       at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
       at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
       at java.lang.Thread.run(Thread.java:595)
      


      I noticed that the "Select User:" drop down which asks you to log in is empty, containing no users. So I checked my database, and noticed that there were no users, groups, or permissions in the database. Perhaps this is fine, but I wasn't sure, so I thought I'd mention it.

      Anyway, does anyone have any idea why this error is occurring, and how to rectify it? And also, what is the generally accepted way to populate the users, groups, and permissions tables -- is this something typically done in the web console (I can't tell because I haven't gotten it to work completely yet), or is this initially done by manually putting values in the database?

      Thanks for your help.

      Brad

        • 1. Re: Web console failing
          Brad O'Hearne Newbie

          This appears to be caused by 3 bugs in the header2.jsp of the 3.1.1 starter's kit. The navigation links are as follows:

          <a href="home.jsp">...</a>
          <a href="admin.jsp">...</a>
          <a href="monitor.jsp">...</a>
          


          The problem is that web.xml specifies the following server mapping for the JSF Servlet:

          <servlet-mapping>
           <servlet-name>FacesServlet</servlet-name>
           <url-pattern>/faces/*</url-pattern>
          </servlet-mapping>
          


          which means that the FacesServlet won't pick up the hrefs listed. Here's how the code should read, and after I made these changes, they worked:

          <a href="faces/home.jsp">...</a>
          <a href="faces/admin.jsp">...</a>
          <a href="faces/monitor.jsp">...</a>
          


          If there's other information known about this problem, I'd be happy to know.

          Thanks,

          Brad


          • 2. Re: Web console failing
            Ronald van Kuijk Master

            Wow, lots of info, so as promised a detailed answer.

            Indeed if you just deploy the app yourself, there is no userdatabase. It is empty. The dropdownlist is no real login. In 3.2 that will change and the user will be taken from the http request, so it is easier to set yourself from any mechanism.

            It could be that the 500 error is cause by not logging in first. That is the (rather basic and not fault tolerant) behaviour of the 3.1 webapp (there is a jira issue for this, but since 3.2 will change have a much more serious and robust webapp, I think it will not be fixed for 3.1.

            Regarding the population of the db, there are some ant tasks (at least with 3.2) that you can call and pass some additional parameters to have the xml config that comes with 3.2 to generate sql insert statements. There also is a jira issue to combine the usermanagement of the jboss portal and create some generic mechanism/app to do this. otoh, the identity service should become more pluggable so you can drop in your own mechanism. Do not expect that for 3.2 however.

            (to be honest, I added my own users by dusting of my sql knowledge and inserted some manually for demo purposes ;-))

            • 3. Re: Web console failing
              Brad O'Hearne Newbie

              Ronald,

              Thanks for the reply. I'm populating a user now manually. I don't know if adding a user alone will do it, as I don't know the impact of not having group, membership, and permissions tables populated (at least for initial login). But I do have a question on populating this table. The JBPM_ID_USER table contains a CLASS_ field which cannot be null. Its one character long, so its obviously some code or flag of some sort. Can you tell me what is supposed to be in this field?

              Once I have this user in the db, if I can login, I'm wondering what I'll actually be able to see, as I have no group, membership, permissions table data. Do you happen to know off the top of your head?

              Thanks again,

              Brad

              • 4. Re: Web console failing
                Ronald van Kuijk Master

                I know it partly. Since I'm working with/on 3.2, I have to switch back somethimes to 3.1. Not a problem for the things I used regulary on 3.1, but not these things.

                Membership and permissions are afaik, not needed. The group is only needed if you want group tasklists etc. Otherwise it can be left empty.

                The class in the user table should contain a 'U', the membership (if needed) a 'M' and guess the group one. The user_ and group_ fields in the membership table should point to the id's of the user and group. NAME_ and ROLE_ can be null (this is all from my 3.2 table, but it could map on 3.1 as well)

                • 5. Re: Web console failing
                  Brad O'Hearne Newbie

                  Ronald,

                  Thanks a lot for your help. The "U" worked like a charm, and allowed me to save my record. Login also worked as a result. However, after logging in, if I try to click on the "Home" link, I get the following in the JBoss log, even though the page seems to render properly:

                  14:12:04,515 INFO [[/jbpm]] WARNING: Component _id13 just got an automatic id,
                  because there was no id assigned yet. If this component was created dynamically
                  (i.e. not by a JSP tag) you should assign it an explicit static id or assign it
                  the id you get from the createUniqueId from the current UIViewRoot component rig
                  ht after creation!
                  


                  Then, if I click the "Home" link a second time, the page mostly renders, except I don't seem to get the table underneath the "Start new process execution" header on the page which has the process definitions listed -- I also get the following in the JBoss log:

                  14:14:20,906 ERROR [[jsp]] Servlet.service() for servlet jsp threw exception
                  java.lang.IllegalStateException: Client-id : _id1 is duplicated in the faces tre
                  e.
                   at org.apache.myfaces.application.jsp.JspStateManagerImpl.checkForDuplic
                  ateIds(JspStateManagerImpl.java:241)
                   at org.apache.myfaces.application.jsp.JspStateManagerImpl.checkForDuplic
                  ateIds(JspStateManagerImpl.java:255)
                   at org.apache.myfaces.application.jsp.JspStateManagerImpl.saveSerialized
                  View(JspStateManagerImpl.java:204)
                   at org.apache.myfaces.taglib.core.ViewTag.doEndTag(ViewTag.java:122)
                   at org.apache.jsp.home_jsp._jspx_meth_f_view_0(home_jsp.java:144)
                   at org.apache.jsp.home_jsp._jspService(home_jsp.java:76)
                   at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
                   at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
                   at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper
                  .java:332)
                   at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:3
                  14)
                   at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
                   at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
                   at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Appl
                  icationFilterChain.java:252)
                   at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationF
                  ilterChain.java:173)
                   at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDisp
                  atcher.java:672)
                   at org.apache.catalina.core.ApplicationDispatcher.processRequest(Applica
                  tionDispatcher.java:463)
                   at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationD
                  ispatcher.java:398)
                   at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDis
                  patcher.java:301)
                   at org.apache.myfaces.context.servlet.ServletExternalContextImpl.dispatc
                  h(ServletExternalContextImpl.java:415)
                   at org.apache.myfaces.application.jsp.JspViewHandlerImpl.renderView(JspV
                  iewHandlerImpl.java:234)
                   at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:
                  300)
                  ...
                  


                  I've tried a user ID of 1 and of 10 in the JBPM_ID_USER table, but that doesn't seem to have any effect. Anyone have any idea what the problem is?

                  Brad

                  • 6. Re: Web console failing
                    Ronald van Kuijk Master

                    The id thing happens sometimes, even with 3.2 head. no idea yet why (not investigated much either). Often klicking again makes it work (do not use the back buttons, it is jsf 1.1)

                    • 7. Re: Web console failing
                      Brad O'Hearne Newbie

                      It turns out this is a bug in JSF. I'll give the solution in just a moment, but first, my proposed solution above to getting the left navigation links to work on the default page before logging in actually causes other problems once you do log in. So there is a bug here, but the bug is either that the login screen should not have "Home", "Administration", and "Monitoring" links, OR a separate block of code should address the not-logged-in vs. logged-in situations. I suppose this could be done with a conditional block or adding a header3.jsp, and header2.jsp could be used prior to login, and header3.jsp could be used after login.

                      Now to the problem:

                      java.lang.IllegalStateException: Client-id : _id1 is duplicated in the faces tree.
                      


                      Apparently this is a JSF bug, and it is caused by a problem in auto-assigning of component ID's to web components where ID's have not been specified (i.e., when created programmatically). The error is occurring in home.jsp, specifically in the block of code which creates the "Start new process execution" data table. The solution is to drop both data tables in home.jsp into subviews that have explicit ID's assigned to them. Here then is the entire code of home.jsp (with changes) that eliminate the _id1 duplication problem:

                      <%@ taglib uri="http://java.sun.com/jsf/html" prefix="h" %>
                      <%@ taglib uri="http://java.sun.com/jsf/core" prefix="f" %>
                      
                      <f:view>
                      
                      <jsp:include page="header1.jsp" />
                      Home
                      <jsp:include page="header2.jsp" />
                      
                      <b><h:messages /></b>
                      
                      <h4>Tasklist</h4>
                      <f:subview id="taskInstanceTable">
                      <h:dataTable value="#{homeBean.taskInstances}" var="taskInstance" headerClass="tableheader" columnClasses="tablecell">
                       <h:column >
                       <f:facet name="header">
                       <h:outputText value="Task Form Link" />
                       </f:facet>
                       <h:commandLink action="#{homeBean.selectTaskInstance}">
                       <f:param name="taskInstanceId" value="#{taskInstance.id}"/>
                       <h:outputText value="#{taskInstance.name}" />
                       </h:commandLink>
                       </h:column>
                       <h:column>
                       <f:facet name="header">
                       <h:outputText value="Process" />
                       </f:facet>
                       <h:outputText value="#{taskInstance.taskMgmtInstance.taskMgmtDefinition.processDefinition.name}" />
                       </h:column>
                       <h:column>
                       <f:facet name="header">
                       <h:outputText value="Version" />
                       </f:facet>
                       <h:outputText value="#{taskInstance.taskMgmtInstance.taskMgmtDefinition.processDefinition.version}" />
                       </h:column>
                      </h:dataTable>
                      </f:subview>
                      
                      <h4>Start New Process Execution</h4>
                      <f:subview id="processInstanceTable">
                      <h:dataTable value="#{homeBean.latestProcessDefinitions}" var="processDefinition" headerClass="tableheader" columnClasses="tablecell">
                       <h:column>
                       <f:facet name="header">
                       <h:outputText value="Start Process Link" />
                       </f:facet>
                       <h:commandLink action="#{homeBean.startProcessInstance}">
                       <f:param name="processDefinitionId" value="#{processDefinition.id}"/>
                       <h:outputText value="#{processDefinition.taskMgmtDefinition.startTask.name}" />
                       </h:commandLink>
                       </h:column>
                       <h:column>
                       <f:facet name="header">
                       <h:outputText value="Process" />
                       </f:facet>
                       <h:outputText value="#{processDefinition.name}" />
                       </h:column>
                       <h:column>
                       <f:facet name="header">
                       <h:outputText value="Version" />
                       </f:facet>
                      
                       <h:outputText value="#{processDefinition.version}" />
                       </h:column>
                      </h:dataTable>
                      </f:subview>
                      
                      <jsp:include page="footer.jsp" />
                      </f:view>
                      


                      If similar duplicate ID problems are happening elsewhere, I'd try the same approach, of wrapping data tables in subviews and explicitly assigning id values to them.

                      Cheers,

                      Brad

                      • 8. Re: Web console failing
                        Ronald van Kuijk Master

                        Brad,

                        I admire your enthousiasm and get the impression (correct me if I'm wrong) you are into UI stuff. I do not know what your timeline is, but let me address some things regarding 3.1 vs 3.2

                        - The 3.1 webapp was 'experimental'
                        - It will not be realy maintained
                        - The 3.2 webapp will be the focus since:
                        - it is facelets instead of jsf/jsp (always trouble as you have experienced)
                        - Authentication in 3.2 webapp will be taken from the container
                        - better separation of roles, at least at the high level of 'participant', 'manager' and 'admin'
                        - customizable forms (RAD + look and feel)
                        - ....

                        So if your timeline is not to short, I'd definately focus on 3.2 from CVS. It's (IMNSHO) worth the try

                        • 9. Re: Web console failing
                          Brad O'Hearne Newbie

                          Ronald,

                          I'll give 3.2 a shot -- quick question though: how stable is the code? I do have some flexibility, and I don't need to leverage all the features of jBPM immediately, but I do wish to have the things I do leverage deployable in a production environment. I do not need real-time, mission-critical performance immediately, but likewise, I couldn't have it failing constantly either. If it is somewhere in between, leaning towards the "very reliable" end of the spectrum, then it would probably work fine for my present needs. It it at least respectable from a stability standpoint in your opinion?

                          Brad

                          • 10. Re: Web console failing
                            Ronald van Kuijk Master

                            A lot of the codebase is shared between 3.1 and 3.2, so it is fairly stable (have not found many issues that were not already in 3.1) although it is an 'alpha'

                            I've given demos to customers using 3.2 just because I can create snappier screens much more quickly.

                            • 11. Re: Web console failing
                              Brad O'Hearne Newbie

                              Ronald,

                              Thanks, I'll take a look! One last question for you:

                              "kukeltje" wrote:

                              I've given demos to customers using 3.2 just because I can create snappier screens much more quickly.


                              What about 3.2 over 3.1 makes you able to create snappier screens more quickly?

                              Thanks,

                              Brad

                              • 12. Re: Web console failing
                                Ronald van Kuijk Master

                                sorry for the delayed response, I have been playing golf in France for 4 days.

                                The advantage is that you can put datepickers, dropdownlists etc in your pages and they work. With 3.1 you can only have 'text inputs'

                                • 13. Re: Web console failing
                                  Brad O'Hearne Newbie

                                  Ronald,

                                  Hey thanks for the tip! That *is* a bonus!

                                  Cheers,

                                  Brad

                                  • 14. Re: Web console failing
                                    Ronald van Kuijk Master

                                    my (until know only personal) intention is to get the variable type in the pd as well and have an automagically generated form (as in 3.1) but WITH the correct input type).

                                    At least until the gpd supports some form generation, but still then, the info has to com from somewhere and I'm not keen on having multiple xml files (so we get an xml hell again where seam tries to prevent one)

                                    Personally (but that is Tom's choice) I'm not keen on having a forms.xml file with just the task name and a reference to a form in it.

                                    <forms>
                                     <form task="Verwerk terugmelding" form="form.terugmelding.xhtml" />
                                     <form task="Rappelleer" form="form.rappelleer.xhtml" />
                                     <form task="Verstuur brief" form="form.brief.xhtml" />
                                    </forms>
                                    


                                    This will (probably) be augmented with variable names and their types so it will become

                                    <forms>
                                     <form task="Verwerk terugmelding" form="form.terugmelding.xhtml">
                                     <variable name="datum" type="date"/>
                                     <variable name="kenteken" type="string"/>
                                     </form>
                                     <form task="Rappelleer" form="form.rappelleer.xhtml">
                                     <variable name="reden" type="collection"/>
                                    </form>
                                     <form task="Verstuur brief" form="form.brief.xhtml" />
                                     ...
                                    
                                    </form>
                                    </forms>
                                    


                                    and afterwards maybe even that the variable is extended with a 'limitation' e.g. a regexp or anything or even dependencies (if var 1 is filled out, var to is required too) but then the requiredness is in the pd and the rest in here.

                                    Or maybe a select-one-radio, select-one-list, select-multiple-list or any other 'view' type that is in JSF.

                                    I'm in favour of putting it all in the PD in the controler part, since it is specific to the implementation of the controller.

                                    hmm... this should be a jbpm-design forum thing....



                                    1 2 Previous Next