| job | The child job. |
| name | A name, can be any text. |
| stop | Read only view of the internal stop flag. |
| timeout |
| Example 1 | An join that waits for two triggers. |
| Configured By | ELEMENT |
| Access | WRITE_ONLY |
| Required | No, but pointless if missing. |
The child job.
| Configured By | ATTRIBUTE |
| Access | READ_WRITE |
| Required | No. |
A name, can be any text.
| Access | READ_ONLY |
Read only view of the internal stop flag. This flag is cleared with a reset.
| Configured By | ATTRIBUTE |
| Access | READ_WRITE |
An join that waits for two triggers. In this example another trigger to run the last job might be a better solution because it wouldn't hog a thread - but there are situations when join is just simpler.
<oddjob>
<job>
<sequential>
<jobs>
<folder>
<jobs>
<state:flag id="apples" xmlns:state="http://rgordon.co.uk/oddjob/state"/>
<state:flag id="oranges" xmlns:state="http://rgordon.co.uk/oddjob/state"/>
</jobs>
</folder>
<state:join id="our-join" xmlns:state="http://rgordon.co.uk/oddjob/state">
<job>
<sequential>
<jobs>
<scheduling:trigger on="${apples}" xmlns:scheduling="http://rgordon.co.uk/oddjob/scheduling">
<job>
<echo>Apples</echo>
</job>
</scheduling:trigger>
<scheduling:trigger on="${oranges}" xmlns:scheduling="http://rgordon.co.uk/oddjob/scheduling">
<job>
<echo>Oranges</echo>
</job>
</scheduling:trigger>
</jobs>
</sequential>
</job>
</state:join>
<echo id="last-job">And that's that!</echo>
</jobs>
</sequential>
</job>
</oddjob>