Initializing and Restoring: Difference between revisions
No edit summary |
No edit summary |
||
| Line 5: | Line 5: | ||
In Obsidian 3.0.0, we introduce an expansion of our [[Implementing_Jobs#Initializing_Job_Schedules | Initializing Job Schedules]] support that leverages the system restore functionality of our API. | In Obsidian 3.0.0, we introduce an expansion of our [[Implementing_Jobs#Initializing_Job_Schedules | Initializing Job Schedules]] support that leverages the system restore functionality of our API. | ||
By default, Obsidian will look for a file on the classpath named /obsidianInitialization.json. You may override the classpath resource name using the system property obsidianInitClasspath. For example, you could add the java system property -DobsidianInitClasspath=/com/mycompany/obsidianInit.json. You can also use a file-based resource by using the system property obsidianInitFile. For example, you could add the java system property -DobsidianInitFile=/var/obsidian/obsidianScheduleInitialization.json. | By default, Obsidian will look for a file on the classpath named <code>/obsidianInitialization.json</code>. You may override the classpath resource name using the system property <code>obsidianInitClasspath</code>. For example, you could add the java system property <code>-DobsidianInitClasspath=/com/mycompany/obsidianInit.json</code>. You can also use a file-based resource by using the system property <code>obsidianInitFile</code>. For example, you could add the java system property <code>-DobsidianInitFile=/var/obsidian/obsidianScheduleInitialization.json</code>. | ||
Note: Initialization only runs on scheduler instances. This means that a standalone Obsidian web application with no scheduler running will not do any initialization based on the presence of the appropriate JSON file. | Note: Initialization only runs on scheduler instances. This means that a standalone Obsidian web application with no scheduler running will not do any initialization based on the presence of the appropriate JSON file. | ||
Revision as of 21:19, 29 January 2015
As of Obsidian 3.0.0
At times, you may wish to perform initialization, backup or restoration of an Obsidian configuration. For example, you may wish to take a known good configuration from a development environment and apply it to a test environment.
In Obsidian 3.0.0, we introduce an expansion of our Initializing Job Schedules support that leverages the system restore functionality of our API.
By default, Obsidian will look for a file on the classpath named /obsidianInitialization.json. You may override the classpath resource name using the system property obsidianInitClasspath. For example, you could add the java system property -DobsidianInitClasspath=/com/mycompany/obsidianInit.json. You can also use a file-based resource by using the system property obsidianInitFile. For example, you could add the java system property -DobsidianInitFile=/var/obsidian/obsidianScheduleInitialization.json.
Note: Initialization only runs on scheduler instances. This means that a standalone Obsidian web application with no scheduler running will not do any initialization based on the presence of the appropriate JSON file.
