This behaviour can be changed by setting the independent
property which will cause execution to continue regardless of the last
executed child state.
stateOperator
property changes the way in which
this jobs state reflects its child states. Oddjob currently supports the
following State Operators:
transient
property to true. Not that when starting
services with this job, persistence is probably not desirable as
it will stop the services from re-starting.
independent | Whether the child jobs are independent or not. |
jobs | The child jobs. |
name | A name, can be any text. |
stateOperator | Set the way the children's state is evaluated and reflected by the parent. |
stop | Read only view of the internal stop flag. |
transient | Is this job transient. |
Example 1 | A simple sequence of two jobs. |
Example 2 | Starting two services. |
Configured By | ATTRIBUTE |
Access | READ_WRITE |
Required | Default is dependent child jobs. |
Whether the child jobs are independent or not.
Configured By | ELEMENT |
Access | WRITE_ONLY |
Required | No, but pointless if missing. |
The child jobs.
Configured By | ATTRIBUTE |
Access | READ_WRITE |
Required | No. |
A name, can be any text.
Configured By | ATTRIBUTE |
Access | READ_WRITE |
Required | No, default is WORST. |
Set the way the children's state is evaluated and reflected by the parent. Values can be WORST, ACTIVE, or SERVICES.
Access | READ_ONLY |
Read only view of the internal stop flag. This flag is cleared with a reset.
Configured By | ATTRIBUTE |
Access | READ_WRITE |
Required | No, default is false. |
Is this job transient. If true state will not be persisted.
A simple sequence of two jobs.
<oddjob> <job> <sequential name="A sequence of two jobs"> <jobs> <echo>This runs first.</echo> <echo>This runs after.</echo> </jobs> </sequential> </job> </oddjob>
Starting two services. To perform odd jobs, in a workshop for instance, this first 'job' is to turn on the lights and turn on any machines required. The service manager encompasses this idea - and this example embelishes the idea. Real odd jobs for Oddjob will involve activities such as starting services such as a data source or a server connection. The concept however is still the same.
<oddjob> <job> <sequential> <jobs> <sequential id="service-manager" stateOperator="SERVICES"> <jobs> <bean id="lights" class="org.oddjob.jobs.structural.ServiceManagerTest$Lights"/> <bean id="machine" class="org.oddjob.jobs.structural.ServiceManagerTest$MachineThatGoes" goes="ping"/> </jobs> </sequential> <echo>The lights are ${lights.are} and the machine goes ${machine.goes}.</echo> </jobs> </sequential> </job> </oddjob>The services are started in order. Once both services have started a job is performed that requires both services. If this configuration were running from the command line, Oddjob would stop the services as it shut down. First the machine would be turned of and then finally the lights would be turned out.