Running a Job - Spring Batch - page 131

• jobDataAsMap : This Map is a collection of all the objects that are injected into
SpringBatchQuartzJobLauncher and any other parameters the Quartz job needs to
run (the location of the files to be deleted and how old they need to be to be).
When the Quartz job is triggered and Spring creates a new instance of
SpringBatchQuartzJobLauncher , Spring uses jobDataAsMap to inject any required dependencies as
required. In this case, you inject the location of the files to be deleted and how old they need to be.
The second bean to look at in launch-context.xml is the cronTrigger bean. You saw earlier how
Quartz uses a trigger to determine when to execute the job. The trigger you're using here determines
when to run based on a cron string. To configure the trigger, you create a
org.springframework.scheduling.quartz.CronTriggerBean with two dependencies: jobDetail references
the job Detail bean, and cronExpression is the cron string used to determine when the job runs. In this
case, you execute deleteFilesJob once every 10 seconds.
The final bean to configure is the one that does all the work: the scheduler. Using Spring's
org.springframework.scheduling.quartz.SchedulerFactoryBean , you register your trigger with the
scheduler. From there, Spring and Quartz take care of the rest.
To get things started, use JobRegistryBackgroundJobRunner to bootstrap the process. Launching this
process using the command in Listing 6-13, you bootstrap Spring, register deleteFilesJob in the
JobRegistry, and start Quartz. With Quartz running, the job executes every 10 seconds as configured.

Listing 6-13. Executing the Job via Quartz

java -jar deleteFiles.jar launch-context.xml jobs/deleteFilesJob.xml
Running jobs via Quartz or another scheduler is a common way to administer batch processes in an
enterprise. Another common aspect of running jobs in an enterprise is the way they're deployed. Given
that many enterprises deploy all or most Java applications to containers of some kind, you should look at
how Spring Batch processes can be run in a container.

Running in a Container
Unlike web applications, batch processes don't require a container to execute. You can build robust and
completely independent batch jobs using readily available frameworks for things like database-
connection pooling, transaction management, and JMS without the need of an application server or
servlet container. That being said, however, there are just as many reasons to run a job in a container as
not.

In an enterprise, there is typically a more robust base of expertise around the configuration and
deployment of container-based applications, where plain Java applications deployed as a collection of
jar files may cause some operations teams pause. Also, resources like database connections (and their
security), JMS queues, and so on may be easier to manage with a standardized configuration within a
container. Let's look at how to deploy and execute jobs from within Tomcat.
Although the ability to configure a large number of resources through the application server is
possible with Spring, their configuration is outside of the scope of this topic. Instead, you focus on
bootstrapping a Spring Batch JobRegistry with the required jobs and triggering their execution.
Bootstrapping the job registry from within a container is easier than what you've been doing up to
now. Instead of relying on CommandLineJobRunner or JobRegistryBackgroundJobRunner for a main method
and to bootstrap your process, Tomcat serves as the means of starting the Java process, and you can use
standard web techniques to bootstrap Spring Batch in your container.
Let's look at how to deploy deleteFilesJob to Tomcat. There are four steps:

1. Update the POM file to a package application as a war file instead of a jar.