Job Scheduler

Joacim Zschimmer added a comment - 09 January 2008 12:34 <include> wird beim Laden der XML-Datei ausgewertet. Ein Fehler dabei, also wenn die Datei nicht lesbar ist oder XPath-Ausdruck kein <params> liefert wirken wie ein XML-Fehler. Für relative Dateinamen gilt das Arbeitsverzeichnis.

Joacim Zschimmer added a comment - 13 January 2008 18:15 Das Attribut node steht im Singular, der XPath-Ausdruck kann aber mehrere Elemente <params> liefern. Die sollen alle nacheinander eingelesen werden? Obwohl das Attribut für den XPath-Ausdruck node heißt, werden nur Elemente akzeptiert.

Andreas Püschel added a comment - 15 January 2008 08:44 ich denke es wäre besser, wenn wir nicht <params><param name="" value=".."/></params adressieren, sondern der XPath-Ausdruck direkt die Parameter <param name=".." value=".."/> als Node List liefert. Das ist aus meiner Sicht dann eindeutig und die Parameter können je nach Ausprägung des XPath Ausdrucks aus unterschiedlichen Knoten stammen. Was hälst du davon?

Andreas Liebert added a comment - 25 January 2008 10:42 - edited Aus dem Telefonat vom 25.1.: - Der XPath-Ausdruck soll eine Nodelist von <param>-Elementen (nicht <params>) zurückgeben - In einem Hot Folder bezieht sich der Pfad für include relativ auf den Pfad der aktuellen XML Datei. Soll ein Pfad relativ zum Scheduler Installationsverzeichnis angegeben werden, so kann ${SCHEDULER_HOME} verwendet werden. Die Änderung bezieht sich auf alle include Elemente (also auch in description und holidays)

Joacim Zschimmer added a comment - 02 February 2008 11:08 Alle <include>, außer in <script>?

Joacim Zschimmer added a comment - 02 February 2008 11:10 Das Basisverzeichnis ist also abhängig davon, woher die XML-Datei kommt. Ist das nicht kompliziert?

Andreas Püschel added a comment - 04 February 2008 08:02 <include> bei <script> ist hier ebenso gemeint, d.h. soll relativ zum Pfad der aktuellen XML-Datei aufgelöst werden. Warum meinst du, sollte es bei <script> nicht angewendet werden? Diese Änderung ist inkompatibel zur bisherigen Verwendung von <include> in scheduler.xml, daher die Unterscheidung, ob mit oder ohne hot folders gearbeitet wird, sonst funktionieren vorhandene Konfigurationen nicht mehr. BTW: Wäre hier nicht die Verwendung einer weiteren Environment-Variablen $SCHEDULER_LIVE angeraten, die den Namen des Live Folders liefert? Der Job Scheduler müsste diese Variable analog zu $SCHEDULER_HOME substituieren.

Joacim Zschimmer added a comment - 04 February 2008 08:13 <script> war nicht aufgeführt. Und wirkt auch anders, denn es wird vom remote Scheduler interpretiert. Dort gibt es aber das Konfigurationsverzeichnis nicht. Sollen wir doch wieder <include> vom lokalen Rechner interpretieren lassen (erscheint mir gut)? SCHEDULER_LIVE wäre die erste Umgebungsvariable, die der Scheduler setzen würde. Wir könnten das neue <params> unter <config> bei der Ersetzung mitverwenden (wobei hier unklar ist, ob vor oder nach Ausführung des Scheduler-Skripts, das Parameter ändern kann.) Oder wir führen spezielle Scheduler-Variablen ein, und so hast Du es wohl gemeint. SCHEDULER_LIVE wäre dann eine interne, vordefinierte Variable. Übrigenes müsste sie konsequenterweise SCHEDULER_CONFIGURATION_DIRECTORY heißen, wenn wir bei den Namensregeln bleiben. Ansonst ist SCHEDULER_LIVE bei euch nicht immer ${SCHEDULER_HOME}/live? Ist das eine eigene Variable wert?

Andreas Liebert added a comment - 04 February 2008 16:43 - edited Ich denke auch, include sollte vom lokalen Scheduler interpretiert werden. Der remote Scheduler ist ja eher ein Slave oder Agent und hat keine Konfigurationsdateien. Etwas anderes ist es, wenn der remote Scheduler ein auf der remote Machine liegendes Script ausführen soll. Dann würde man dafür jedoch nicht include verwenden, sondern den Scriptaufruf in das <script> Element schreiben. Den SCHEDULER_LIVE Absatz verstehe ich nicht. $SCHEDULER_LIVE ist doch gar nicht die erste Umgebungsvariable, es gibt doch $SCHEDULER_HOME. Da configuration_directory einstellbar ist, sollte man nicht davon ausgehen, dass es immer ${SCHEDULER_HOME}/config/live ist. Wir liefern das zwar so aus, es gibt jedoch auch Situationen, in denen wir die Verzeichnisstruktur zerpflücken.

Joacim Zschimmer added a comment - 21 February 2008 09:52 Ich fasse JS-215 und JS-240 zusammen: A) <script><include> <include> in <script> wird nicht mehr am remote Scheduler interpretiert, sondern immer lokal. Die inkludierten Dateien werden lokal gelesen. B) Neu einzubauen: <include live_file="pfad"> 1) Für <include> in diesen Elementen:        <job><script>        <job><params>        <job><description>        <config><holidays>        <job><run_time><holidays> 2) pfad ist relativ zum Pfadnamen der Datei, die den <include> enthält (der Scheduler wird diese Information durchreichen). 3) Wenn <include> nicht aus einer Datei eines Konfigurationsverzeichnisses kommt (also per TCP oder scheduler.xml), wird als Basisverzeichnis das Konfigurationsverzeichnis ("live/") angenommen. 4) pfad kann sich nur im Verzeichnisbaum der Konfiguration (entweder live/ oder cache/) bewegen. ".." ist soweit erlaubt. 5) "/" ist das Wurzelverzeichnis der Konfiguration. C) Überwachung von <include live_file=".."> in <job><params> Ändert sich die inkludierte Datei, wirkt das wie eine Änderung der Konfigurationsdatei des Jobs, die daraufhin neu eingelesen wird. D) <params><include> <params> wird um einen <include> erweitert. Mit dem neuen Attribute node= wird ein X-Path-Ausdruck angegeben, der die <param>-Elemente adressiert.

Joacim Zschimmer added a comment - 26 February 2008 16:07 <config include_path="..."> akzeptiert jetzt Umgebungsvariablen.