Thank you Martin, you actually helped me and I got it to work!! I'm going to summarize it up because I think that certain things are not so intuitive for a "jBPM scheduler"-newbie like me.
First of all, the default implementation of the scheduler service, provided by jBPM, is DbSchedulerServiceFactory, which uses the database to store information about scheduled actions associated with timers. This means that a database is needed even to write a simple JUnit test case that uses timers and this justifies the need to deploy your process definition (it's needed to store the related timers and timer jobs in the database, as well). I would assume that a different scheduler service implementation could be made to avoid the use of a database, however let's talk about the default implementation. Even if a database is needed, there's no need to extend AbstractDbTestCase, which provides many methods to create and clean the schema and to interact with the database. In fact, in the simplest case, jBPM (thanks to Hibernate) will create automatically an in-memory database for you when you go to deploy your process definition and/or schedule a timer action. In this case, however, you should take care of the db lifecycle, however I think (but I may be wrong) that if you destory the jbpmConfiguration (by calling close) the in-memory db will be destroyed too... Anyway, in my case I was running an only test method, so it's not so important how the db is handled between multiple test methods invocations. In my previous example (TRIAL 2) timer actions were correctly saved in the database by the DbSchedulerServiceFactory, but they were not executed because no JobExecutor thread was started. The JobExecutor thread is actually a thread that periodically reads from the database, searching for saved timer actions (jobs) and executes them. So, if I change my test case by calling jbpmConfiguration.startJobExecutor() just after the configuration creation, I make sure that the "scheduler" is started. Actually, I would rather say that there is no scheduler to start, but that the default scheduler service implementation expects that a JobExecutor thread is present to execute timer actions. In other words, the JobExecutor is itself part of the default scheduler service implementation. I think that this only sentence would be enough to say that my original problem is not so stupid as kukeltje says and that the documentation could be drastically improved on this subject (I'm also wondering what is http://docs.jboss.com/jbpm/v3.2/userguide/html_single/#schedulerdeployment all about!?). Anyway, this is not enough, because another action is needed in order to make the JobExecutor run timer actions in my test case: just after the signal invocation, that moves my process instance to the waiting state (with attached timer), I have to close the jBPM context in order to commit things (the deployed process definition, the process instance state and the related saved timers and jobs), otherwise the JobExecutor, which works on another thread, wouldn't find anything to executoe. Having the whole scenario cleared, this sounds reasonable and obvious, but I think it might not be so straight away for a first time user that is writing a simple JUnit test case. Using the AbstractDbTestCase class mentioned by Martin, this would be automatically achieved because the method processJobs(long) does a "commit" before starting the JobExecutor. Thank you again Martin and please correct me if I've written something wrong. Anyway, if this is considered to be a simple answer to a basic question (as kukeltje said)... well, I'm wondering why kukeltje couldn't write it himself: he would have certainly spent much less time that writing his two previous smart posts, as Martin's kind answer demonstrated. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4267259#4267259 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4267259 _______________________________________________ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
