Trigger's own state

[Roman Mishin]

Trigger's own state property is overriden (or shadowed) by the required state of the job it will trigger on.
So it is impossible to rely on the trigger's own state (for example to trigger on it with another trigger).

Though I found that it is possible to reflect the real trigger's state via the state:mirror job.

Am I correct? Is such behaviour worth fixing (i.e. making the properties separate)?

I am using Oddjob 1.4.0.

[Roman Mishin]

I post here my solution to "how to trigger on another trigger".

Is there a problem? Might not be a problem. May be just a kind of misunderstanding how to accomplish it another way.

1. The job that is set to be triggered might not be triggered at all (the trigger is canceled).
   The job's state will not change so we can not watch for the job.

2. The trigger can potentially reflect the state of the job after it has ran for some time.
   But the trigger's state will not tell us if it was canceled. It becomes COMPLETE: so the job was not ran and the trigger is COMPLETE.

Might be a slight semantic misalignment. (The <check> job has similar..)

How to continue processing in an event-driven style?

Suppose there is a trigger (FileUnzipTrigger) that will run a job (FileUnzipJob)

<scheduling:trigger id="FileUnzipTrigger" name="on Updated | {$path}/{$file}"
                    on="${FileUpdateFlag}"
                    state="COMPLETE" cancelWhen="FINISHED">
  <job>

    <sequential id="FileUnzipJob" name="Unzip {$what} from {$file}">
      <jobs>

        <mkdir name="Make Directory" dir="C:/Files/{$unZipPath}/"/>

        <exec name="Unzip File" dir="C:/Files/{$unZipPath}/">7z e ../"{$file}" "{$what}" -y
          <stdout><stdout/></stdout>
          <stderr><stderr/></stderr>
        </exec>

      </jobs>
    </sequential>

  </job>
</scheduling:trigger>

A job can be created to serve as a boolean flag and other jobs further in processing line can be set to watch for this job instead.

<parallel join="true" id="FileUnzipFlag" name="Unziped | {$path}/{$file}">
  <jobs>

    <state:equals name="Complete" state="COMPLETE">
      <job>

        <state:mirror name="Unzip File Job" job="${FileUnzipJob}"/>

      </job>
    </state:equals>

    <state:mirror name="Unzip File Trigger" job="${FileUnzipTrigger}"/>

  </jobs>
</parallel>

[Rob Gordon]

Hi - yes, this isn't easy. I will change Trigger state to INCOMPLETE when cancelled which will make this easier.

My solution is below, but it is no more elegant than yours.

Hope it helps,
Rob.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<oddjob>
    <job>
        <sequential>
            <jobs>
                <folder>
                    <jobs>
                        <sequential name="Run Me Manually">
                            <jobs>
                                <input>
                                    <requests>
                                        <input-text default="COMPLETE" prompt="Flat State" property="flagState"/>
                                    </requests>
                                </input>
                                <state:flag id="FileUpdateFlag" state="${flagState}" xmlns:state="http://rgordon.co.uk/oddjob/state"/>
                            </jobs>
                        </sequential>
                    </jobs>
                </folder>
                <scheduling:trigger id="FileUnzipTrigger" name="on Updated | {$path}/{$file}" on="${FileUpdateFlag}" state="FINISHED" xmlns:scheduling="http://rgordon.co.uk/oddjob/scheduling">
                    <job>
                        <state:if xmlns:state="http://rgordon.co.uk/oddjob/state">
                            <jobs>
                                <state:mirror job="${FileUpdateFlag}"/>
                                <sequential id="FileUnzipJob" name="Unzip {$what} from {$file}">
                                    <jobs>
                                        <echo name="Make Directory"><![CDATA[Make Directory]]></echo>
                                        <echo name="Unzip File"><![CDATA[Unzip File]]></echo>
                                    </jobs>
                                </sequential>
                                <state:flag state="INCOMPLETE"/>
                            </jobs>
                        </state:if>
                    </job>
                </scheduling:trigger>
                <scheduling:trigger cancelWhen="ENDED" name="After File Unzipped Trigger" on="${FileUnzipTrigger}" state="DONE" xmlns:scheduling="http://rgordon.co.uk/oddjob/scheduling">
                    <job>
                        <echo><![CDATA[Doing stuff after file unzipped.]]></echo>
                    </job>
                </scheduling:trigger>
            </jobs>
        </sequential>
    </job>
</oddjob>

[Roman Mishin]

Hi, Rob. Your solution is good. Because everything about the trigger is in one branch. Thank you.

I also find a good point in mine such that a set of such flags (if there are many) will visually (V/X) indicate which events processed which not. While a set of triggers themselves will visually (V/X) indicate if there were any errors, because in the current Oddjob implementation only INCOMLETE or EXCEPTION states will propagate up to the trigger, which is also kind of useful.