Previous: Infrastructure Up: Customization Next: Design

Add your Own Job Executions

To add job executions from another process just execute a job (e.g. from command line) against the same database that is used by Spring Batch Admin. The UI picks up the meta data from the usual Spring Batch tables.

Create Your Own Standalone Application

To create a standalone application and run jobs against the Spring Batch Admin database, the easiest thing to do is include the spring-batch-admin-*.jar files in the classpath of your application and use the same conventions to override and extend as you would for a web application.

If you do that then in particular for a standalone application that runs a single job in its own process, you will want to override the jobLauncherTaskExecutor as described above, and possibly also the jobLoader in addition to providing data source properties. Here's an example configuration file to drive a job:

<beans ...>

  <import resource="classpath*:/META-INF/spring/batch/bootstrap/manager/*.xml" />
  <import resource="classpath*:/META-INF/spring/batch/jobs/*.xml" />

  <!-- ensure job runs in foreground thread -->
  <bean id="jobLauncherTaskExecutor" class="org.springframework.core.task.SyncTaskExecutor"/>
  <!-- prevent loading of other jobs by overriding the loader in the main bootstrap context -->
  <bean id="jobLoader" class="java.lang.String"/>

</beans>

With the job defined in /META-INF/spring/batch/jobs/*.xml you can use the CommandLineJobRunner from Spring Batch to load the file above, and launch the job by name, e.g.

$ java org.springframework.batch.core.launch.support.CommandLineJobRunner \
  -next config/launch-context.xml jobName

Add your Own Jobs For Launching in the UI

Include Spring XML files in META-INF/spring/batch/jobs. Each file should be self-contained (except for Batch execution components like the jobRepository which are provided centrally), and carry one or more bean definitions for a Spring Batch Job. When the application starts these files are scanned and loaded as child contexts, and then the jobs are registered with a JobRegistry in the parent. Because they are child contexts you don't have to worry about name clashes between different XML files or different contributing JARs (except for the jobs which must have unique names).

As a convenience, the child contexts inherit property placeholders and AOP configuration from the parent (this is not the default behaviour for a child context in Spring). This means you can control those things centrally if you need to. Of course, the child can always create its own placeholder definition and AOP configuration, but these will not affect the parent or any of its siblings.

Create your own Web Application

Hints for custom applications:

  • Look at the sample.
  • Create a war project with an index.jsp and a web.xml (from the sample or from the spring-batch-admin-resources.jar).
  • Include the spring-batch-admin-*.jar files in WEB-INF/lib. In the sample this is done simply by making the WAR depend on those jar files in the Maven pom.
  • Optionally add your own jobs in the classpath under META-INF/spring/batch/jobs/*.xml.
  • Deploy the web app.

Previous: Infrastructure Up: Customization Next: Design