-
1. Re: Scheduler and asynchronous flow in in web app
kukeltje Dec 4, 2008 2:31 PM (in response to jeklund)afaik, it now is a servletfilter...
-
2. Re: Scheduler and asynchronous flow in in web app
jeklund Dec 4, 2008 6:45 PM (in response to jeklund)Thank you Ronald (for this any _many_ other posts I've read on this forum)!
I didn't find anything on this changes in Jira or anywhere else related to "JbpmThreadsServlet"..
Does anyone know
1. the location of documentation of how to configure it the new way? or
2. the name of the new filter? or
3. in which issue this change was made (so I could look up the made changes to the SVN and work backwards from there)
Best Regards,
Johan -
3. Re: Scheduler and asynchronous flow in in web app
kukeltje Dec 4, 2008 7:42 PM (in response to jeklund)1:
Configuration is still done the same as before in jbpm.cfg.xml. The current docs are still valid to that regard.
2:
Sorry, it is a ServletContextListener (JobExecutorLauncher) and used in the jsf-console.war in the lib dir after running the installer.. You can see how it is done in the corresponding web.xml in that file. For the source see org.jbpm.web in jbpm-jpdl-sources.jar in the src dir after running the installer.
hmmm... the servlet config is also still in the web.xml .... strange but anyhow...
3: No need to I think with the comments above..
And thanks ;-) -
4. Re: Scheduler and asynchronous flow in in web app
jeklund Dec 5, 2008 9:15 AM (in response to jeklund)Thanks again Ronald!
After further debugging I found that the reminder-tag sends a reminder every 30 secs both with and without the additional JobExecutorLauncher. So the timer "works" in some aspect. I guess Seam starts the scheduler without leaving anything in the log.. sorry for not testing properly before posting.
The task causing the error is a nester Seam Pageflow and was started with@In private Pageflow pageflow; @StartTask public String startTask() { pageflow.begin(TaskInstance.instance().getName()); initializeProcessVariables(); return SECUREPAGESDIR + TaskInstance.instance().getName() + ".jsp"; }
and ended with<page name="showIncompleteTasksApprove" view-id="/secure/taskList.jsp"> <end-task transition="Approve"/> <redirect/> </page>
which results in14:37:39,174 WARN [ProxyWarnLog] Narrowing proxy to class org.jbpm.graph.node.TaskNode - this operation breaks == 14:37:39,185 ERROR [GraphElement] action threw exception: service 'scheduler' unavailable org.jbpm.svc.JbpmServiceException: service 'scheduler' unavailable at org.jbpm.svc.Services.getCurrentService(Services.java:97) at org.jbpm.svc.Services.getCurrentService(Services.java:87) at org.jbpm.scheduler.def.CancelTimerAction.execute(CancelTimerAction.java:45) at org.jboss.seam.bpm.SeamUserCodeInterceptor$1.process(SeamUserCodeInterceptor.java:80) at org.jboss.seam.bpm.SeamUserCodeInterceptor$ContextualCall.run(SeamUserCodeInterceptor.java:33) at org.jboss.seam.bpm.SeamUserCodeInterceptor.executeAction(SeamUserCodeInterceptor.java:74) at org.jbpm.graph.def.GraphElement.executeAction(GraphElement.java:254) at org.jbpm.graph.def.GraphElement.executeActions(GraphElement.java:212) at org.jbpm.graph.def.GraphElement.fireAndPropagateEvent(GraphElement.java:182) at org.jbpm.graph.def.GraphElement.fireEvent(GraphElement.java:166) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.hibernate.proxy.pojo.javassist.JavassistLazyInitializer.invoke(JavassistLazyInitializer.java:173) at org.jbpm.taskmgmt.def.Task_$$_javassist_2023.fireEvent(Task_$$_javassist_2023.java) at org.jbpm.taskmgmt.exe.TaskInstance.end(TaskInstance.java:444) at org.jbpm.taskmgmt.exe.TaskInstance.end(TaskInstance.java:413) at org.jboss.seam.bpm.BusinessProcess.endTask(BusinessProcess.java:214) at org.jboss.seam.pageflow.Page.execute(Page.java:103) at org.jbpm.graph.def.Node.enter(Node.java:314) at org.jbpm.graph.def.Transition.take(Transition.java:151) at org.jbpm.graph.def.Node.leave(Node.java:389) at org.jbpm.graph.exe.Token.signal(Token.java:192) at org.jbpm.graph.exe.Token.signal(Token.java:155) at org.jbpm.graph.exe.ProcessInstance.signal(ProcessInstance.java:283) at org.jboss.seam.pageflow.Pageflow.signal(Pageflow.java:485) at org.jboss.seam.pageflow.Pageflow.navigate(Pageflow.java:341) at org.jboss.seam.jsf.SeamNavigationHandler.handleNavigation(SeamNavigationHandler.java:40) at com.sun.faces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:130) at javax.faces.component.UICommand.broadcast(UICommand.java:387) at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:475) at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:755) at com.sun.faces.lifecycle.InvokeApplicationPhase.execute(InvokeApplicationPhase.java:82) at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:100) at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:118) at javax.faces.webapp.FacesServlet.service(FacesServlet.java:265) 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.debug.hot.HotDeployFilter.doFilter(HotDeployFilter.java:54) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:38) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90) 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:45) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69) at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:73) 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:182) 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)
My theory is that, Seam has in some way made the jbpmContext invisible for the nested action endTask and this causes CancelTimerAction to fail in retrieving a reference to the scheduler-service. Without the reminder-tag, ending the task works fine.
1. Is there some way of propagating this context all the way through the pageflow?
2. Would it be better/possible to write a custom action for ending the task, save the result and use a decision to branch on the result after the task is done?
These questions might be better suited for a Seam forum, but I'm not sure what is jBPM and what is Seam here..
Best Regards,
Johan -
5. Re: Scheduler and asynchronous flow in in web app
kukeltje Dec 6, 2008 12:14 PM (in response to jeklund)These questions might be better suited for a Seam forum, but I'm not sure what is jBPM and what is Seam here..
I think it is mostly seam (or their wrappers)
1: That surely is seam
2: what do you mean by custom action? A jbpm actionhandler or a method in a bean called from jsf? -
6. Re: Scheduler and asynchronous flow in in web app
jeklund Dec 6, 2008 5:58 PM (in response to jeklund)1. I'll see if anyone in the Seam community has any ideas. (http://www.seamframework.org/Community/SchedulerIssueInWebAppWithMixedJBPMAndPageflow for anyone following this thread.)
2. I was thinking of creating a custom pageflow-action instead of<end-task transition="Approve"/>
that would somehow replace the new jbpmContext with the original one and then programatically end the task. But after thinking this trough I don't think it's a good option.
Thanks again for all your help.