In unit test, you can use managementService to execute Job/Timer.
ManagementService managementService = processEngine.getManagementService();
Job job = managementService.createJobQuery().timers().processInstanceId(piId).uniqueResult();
Thanks for the reply
The code you wrote is exactly what I am doing, but this way I am explicitly triggering the job / timer. I need the timer to fire on its own after its duedate. This should be done be a scheduler or so
I have known what you mean. But I don't recommand to run a JobExecutor in the unit test. In the unit test environment, we shouldn't depend the container environment to do things like that. Furthermore, if you have configured a JobExecutor and wait for '20 seconds', you can't exactly decide when the timer was executed, because the jobexecutor doesn't run in real time, commonly it will wait thirty second between every execution.
So I think you shouldnot depend a JobExecutor to decide whether the Timer executed correctly. May be you can setup a integration test environment to verify this.
Ok, I see what you mean
Will the timer work properly in a web container like tomcat?
I didn’t deploy the workflow in a web application yet, but I assume that the timer should be triggered automatically according to its duedate and repeat settings.
Did you try such a scenario?
You can import jbpm.jobexecutor.cfg.xml to the jbpm.cfg.xml, then when you startup the ProcessEngine, JobExecutor will startup automaticly. The configuration is as following:
<?xml version="1.0" encoding="UTF-8"?>
<import resource="jbpm.businesscalendar.cfg.xml" />
<import resource="jbpm.tx.hibernate.cfg.xml" />
<import resource="jbpm.jpdl.cfg.xml" />
<import resource="jbpm.identity.cfg.xml" />
If you user 'show_sql=true' in hibernate, you will see many SQL on the console, it is said that JobExecutor is trying to find Job from database.
The JobExecutor needn't a servlet container like tomcat, because it is no more than a TheadPool. You can try like this in your unit test.