The opening paragraphs of this chapter laid out a list of benefits for the job repository, such as the ability to maintain state from execution to execution and trend run statistics from run to run. However, you'll almost never use an in-memory repository for those reasons. That's because when the process ends, all of that data is lost. So, why would you use an in-memory repository at all?

The answer is that sometimes you don't need to persist the data. For example, in development, it's common to run jobs with an in-memory repository so that you don't have to worry about maintaining the job schema in a database. This also allows you to execute the same job multiple times with the same parameters, which is a must-have in development. You might also run a job using the in-memory repository for performance reasons. There is a cost to maintaining job state in a database that may not be needed. Say, for instance, that you're using Spring Batch to do a data migration, moving data from one database table to another; the destination table is empty to start, and you have a small amount of data to migrate. In a case like this, the overhead of setting up a Spring Batch schema and using it may not make sense. Situations that don't need Spring Batch to manage restarts and so on can use the in-memory option.

The JobRepository you've been using so far is configured in the launch-context.xml file. In the previous examples, you've configured the job repository using MySQL. To configure your job to use an in-memory repository, you use the org.springframework.batch.core.repository.support.MapJobRepositoryFactoryBean, as shown in Listing 5-1. Notice that a transaction manager is still required. This is because the data the JobRepository stores is still dependent on transaction semantics (rollback, and so on), and business logic may depend on transactional stores as well. The transaction manager configured in the listing, org.springframework.batch.support.transaction.ResourcelessTransactionManager, actually doesn't do anything with transactions; it's a dummy transaction manager that provides a dummy transaction.

<?xml version="1.0" encoding="UTF-8"?>
<beans:beans xmlns="http://www.springframework.org/schema/batch"
    xmlns:beans="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.springframework.org/schema/beans
        http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
        http://www.springframework.org/schema/batch
        http://www.springframework.org/schema/batch/spring-batch-2.1.xsd">
    <beans:bean id="transactionManager"
class="org.springframework.batch.support.transaction.
ResourcelessTransactionManager"/>

    <beans:bean id="jobRepository"
class="org.springframework.batch.core.repository.support.
MapJobRepositoryFactoryBean" p:transactionManager-ref="transactionManager" />
...

If you take the HelloWorld example from Chapter 2 and configure it to use the in-memory elements of Listing 5-1, you see that you can run the job over and over without Spring Batch throwing an exception for running the same job with the same parameters multiple times.

You should keep in mind a couple of limitations when using an in-memory job repository. First, as already stated, because the storage of data is in memory, once a JVM is restarted the data is lost. Second, because synchronization occurs in the memory space of a particular JVM, there is no guarantee that a given job won't be executed with the same given parameters by executing the same job in two JVMs. Finally, if your job is using any of the multithreading options (multithreaded step, parallel flows, and so on) provided by Spring Batch, this option won't work.

That's it for the in-memory option. By making a small configuration tweak, you can prevent yourself from having to deal with setting up a database to run your batch jobs. However, given the limitations of this approach and the features that a persistent job repository provides, most of the time you'll use a database to back your job repository. With that in mind, let's look at configuring the job repository in a database.

Using a Database Repository is the predominant way to configure a job repository. It allows you to utilize all the benefits of a persistent store with little impact on your job's overall performance. Later, this chapter looks at some hard numbers to illustrate the cost of using a database.

For now, however, let's start by looking at the MySQL configuration you've been using in the examples. You can see the configuration in Listing 5-2. In this case, you begin with the datasource. This example uses the org.apache.commons.dbcp.BasicDataSource provided by Apache Commons, but any datasource you want to use is ok. Listing 5-2 sets the values of the various properties (driver class, database URL, username, and password) via properties in the batch.properties file. This allows you to configure those properties specific to the environment you're working in (your production environment has different values than your test environment, which has different values than your local development).

<beans:bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource">
    <beans:property name="driverClassName" value="${batch.jdbc.driver}" />
    <beans:property name="url" value="${batch.jdbc.url}" />
    <beans:property name="username" value="${batch.jdbc.user}" />
    <beans:property name="password" value="${batch.jdbc.password}" />
</beans:bean>

<beans:bean id="transactionManager"
    class="org.springframework.jdbc.datasource.DataSourceTransactionManager"
    lazy-init="true">
    <beans:property name="dataSource" ref="dataSource" />
</beans:bean>

<job-repository id="jobRepository" data-source="dataSource"
    transaction-manager="transactionManager"/>

The next thing you configure is the transaction manager. Again, you keep it simple here by using the basic DataSourceTransactionManager provided by Spring, but any transaction manager will do. DataSourceTransactionManager has a single dependency: an actual datasource that you've configured. The last aspect of the transaction manager is that it's configured to be lazily initialized^[15] which is optional per the Spring documentation but because Spring Batch's shell project has it configured this way, there is no reason to change it.

Finally you come to the job repository factory. The first thing to call out about this configuration is that you don't use the regular bean tag. Instead, Spring Batch provides a tag specific for configuring the job repository. In order to configure the job repository this way, you need to add references to the Spring Batch XSD to launch-context.xml as you did in Listing 5-1, because it isn't included by default. With the job-repository tag, the only attribute that is required is id. By default, Spring autowires the data-source and transaction-manager attributes of JobRepositoryFactoryBean with beans named dataSource and transactionManager, respectively.

In either configuration, using the bean tag or the job-repository tag, you reference the second of two job repository factories provided with Spring Batch. The first is org.springframework.batch.core.repository.support.MapJobRepositoryFactoryBean, which you use for an in-memory job repository. The second is org.springframework.batch.core.repository.support.JobRepositoryFactoryBean. The JobRepositoryFactoryBean that this configuration demonstrates uses a database as the method for maintaining state in the job repository. To access the underlying database, you need to satisfy its two dependencies: a datasource and a transaction manager, both of which are configured in Listing 5-2.

<job-repository id="jobRepository" data-source="dataSource"
    transaction-manager="transactionManager" table-prefix="SAMPLE_"/>

<job-repository id="jobRepository" data-source="dataSource"
    transaction-manager="transactionManager" max-varchar-length="3000"/>

<job-repository id="jobRepository" transaction-manager="transactionManager"
    data-source="dataSource" isolation-level-for-create="READ_COMMITTED"/>

<beans:bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource">
    <beans:property name="driverClassName" value="${batch.jdbc.driver}" />
    <beans:property name="url" value="${batch.jdbc.url}" />
    <beans:property name="username" value="${batch.jdbc.user}" />
    <beans:property name="password" value="${batch.jdbc.password}" />
</beans:bean>

<beans:bean id="transactionManager"
   class="org.springframework.jdbc.datasource.DataSourceTransactionManager"/>

<aop:config>
    <aop:advisor
pointcut="execution(*org.springframework.batch.core.repository..*Repository+.*(..))"/>
    <advice-ref="txAdvice" />
</aop:config>

<tx:advice id="txAdvice" transaction-manager="transactionManager">
    <tx:attributes>
        <tx:method name="*" />
    </tx:attributes>
</tx:advice>

<beans:bean id="jobRepository"
class="org.springframework.batch.core.repository.support.JobRepositoryFactoryBean"
p:transactionManager-ref="transactionManager" p:dataSource-ref="dataSource" />

The org.springframework.batch.core.explore. JobExplorer interface is the starting point for all access to historical and active data in the job repository. Figure 5-1 shows that although most of the framework accesses the information stored about job execution through the JobRepository, the JobExplorer accesses it directly from the database itself.

Figure 5.1. The relationship between the job administration components

The underlying purpose of the JobExplorer is to provide read-only access to the data in the job repository. The interface provides seven methods you can use to obtain information about job instances and executions. Table 5-1 lists the available methods and their use.

As you can see, the entire job repository is available from the methods exposed by the JobExplorer interface. However, before you can put the JobExplorer to use, you need to configure it. Listing 5-7 shows how to configure the JobExplorer in the launch-context.xml file.

<beans:bean id="jobExplorer"
class="org.springframework.batch.core.explore.support.JobExplorerFactoryBean"
p:dataSource-ref="dataSource" />

The JobExplorer is configured just like any other Spring bean with a single dependency—a datasource—so it can be injected into any of your other elements. Note that unlike most of the other Spring Batch components you've configured that have a dependency of the JobRepository, this one depends on a datasource. The reason is that, as mentioned earlier, the JobExplorer doesn't obtain its information from the JobRepository. Instead, it goes directly to the database for its information.

To see how the JobExplorer works, you can inject it into the HelloWorld tasklet from the previous examples. From there, you can see what you can use the JobExplorer for. In Listing 5-8, you configure the HelloWorld tasklet with the JobExplorer injected.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns:batch="http://www.springframework.org/schema/batch"
    xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.springframework.org/schema/beans
        http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
        http://www.springframework.org/schema/batch
        http://www.springframework.org/schema/batch/spring-batch-2.1.xsd">

    <import resource="../launch-context.xml"/>

    <bean id="helloWorld"
        class="com.apress.springbatch.chapter5.HelloWorld">
        <property name="explorer" ref="jobExplorer"/>
    </bean>

    <batch:step id="helloWorldStep">
        <batch:tasklet ref="helloWorld"/>
    </batch:step>

    <batch:job id="helloWorldJob">
        <batch:step id="step1" parent="helloWorldStep"/>
    </batch:job>
</beans>

With the JobExplorer configured, there are a number of things you can do with it. Within the Spring Batch framework, you can use the JobExplorer in the RunIdIncrementer you looked at in Chapter 4 to look up the previous run.id parameter value. Another place it's used is in the Spring Batch Admin web application to determine whether a job is currently running before launching a new instance. In the example, you use it to determine whether this is the first time you've run this JobInstance. If it is, you print the message "Hello, Michael!" where Michael is a value passed in. If it isn't the first time you've run the job, you update the message to "Welcome back Michael!" Listing 5-9 has the updated code for this tasklet.

package com.apress.springbatch.chapter5;

import java.util.List;

import org.springframework.batch.core.JobInstance;
import org.springframework.batch.core.StepContribution;
import org.springframework.batch.core.explore.JobExplorer;
import org.springframework.batch.core.scope.context.ChunkContext;
import org.springframework.batch.core.step.tasklet.Tasklet;
import org.springframework.batch.repeat.RepeatStatus;

public class HelloWorld implements Tasklet {

private static final String HELLO = "Hello, %s!";
    private static final String WELCOME = "And then we have %s!";
    private static final String JOB_NAME = "helloWorldJob";

    private JobExplorer explorer;

    public RepeatStatus execute(StepContribution stepContribution,
                                ChunkContext chunkContext) throws Exception {
        List<JobInstance>instances =
            explorer.getJobInstances(JOB_NAME, 0, Integer.MAX_VALUE);

        String name = (String) chunkContext.getStepContext()
                                           .getJobParameters()
                                           .get("name");

        if (instances != null && instances.size() > 1) {
            System.out.println(String.format(WELCOME, name));
        } else {
            System.out.println(String.format(HELLO, name));
        }

        return RepeatStatus.FINISHED;
    }

    public void setExplorer(JobExplorer explorer) {
        this.explorer = explorer;
    }
}

The code in Listing 5-9 begins by obtaining all the JobInstances for helloWorldJob. Once it has the list, it determines whether the job has been run before. If it has, you use the "Welcome back" message. If this is the first time the job is being run, you use the "Hello" message.

With the code and configuration in place, run the job twice so you can see both halves of the if statement execute. Listing 5-10 shows the important output for each job.

Run 1 executed with the command java -jar metadata-0.0.1-SNAPSHOT.jar name=Michael
2010-12-17 22:42:50,613 DEBUG
org.springframework.batch.core.launch.support.CommandLineJobRunner.main()
[org.springframework.batch.core.scope.context.StepContextRepeatCallback] - <Chunk execution
starting: queue size=0>

Hello, Michael!

2010-12-17 22:42:50,619 DEBUG
org.springframework.batch.core.launch.support.CommandLineJobRunner.main()
[org.springframework.batch.core.step.tasklet.TaskletStep] - <Applying contribution:
[StepContribution: read=0, written=0, filtered=0, readSkips=0, writeSkips=0, processSkips=0,
exitStatus=EXECUTING]>

Run 2 executed with the command java -jar metadata-0.0.1-SNAPSHOT.jar name=John
2010-12-17 22:44:49,960 DEBUG
org.springframework.batch.core.launch.support.CommandLineJobRunner.main()
[org.springframework.batch.core.scope.context.StepContextRepeatCallback] - <Chunk execution
starting: queue size=0>

And then we have John!

2010-12-17 22:44:49,965 DEBUG
org.springframework.batch.core.launch.support.CommandLineJobRunner.main()
[org.springframework.batch.core.step.tasklet.TaskletStep] - <Applying contribution:
[StepContribution: read=0, written=0, filtered=0, readSkips=0, writeSkips=0, processSkips=0,
exitStatus=EXECUTING]>

This section looked at how to access data in the job repository via the JobExplorer. You use APIs like the JobExplorer to access the data to use it in a safe way. Although it isn't considered good practice to manipulate the job repository directly, that doesn't mean the data it maintains is hands-off. In fact, you can control what happens in your jobs programmatically by manipulating the job repository. You do this using the JobOperator.

The JobOperator is very similar to the JobExplorer when you look at the method names. However, whereas the JobExplorer provides a read-only look into the data in the job repository, the JobOperator exposes only as much as required to take action on it. The org.springframework.batch.core.launch. JobOperator interface lets you execute basic administrative tasks programmatically in a job.

The JobOperator's interface consists of 11 methods, which are outlined in Table 5-2.

Up to now this book has been using a basic java command line command to launch Spring Batch's CommandLineJobRunner to run jobs. To see the JobOperator in action, you create a JMX JobRunner that allows you to execute a job via a JMX console. To get started, you have to write a main method that keeps the Spring application running without actually doing anything. Listing 5-11 shows how you do that.

package com.apress.springbatch.chapter5;

import org.springframework.context.ApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;

public class Batch {

    @SuppressWarnings("unused")
    public static void main(String[] args) {
        try {
            ApplicationContext context =
                new ClassPathXmlApplicationContext("launch-context.xml");

            Object lock = new Object();

            synchronized (lock) {
                lock.wait();
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

When you have the code written to launch your Spring application and keep it running, you can write JMXJobRunner. To do this, all you do is write a POJO that starts a job based on the job name passed in. As you can see in Listing 5-12, the code to accomplish this isn't much more than a wrapper around a JobOperator instance.

package com.apress.springbatch.chapter5;

import org.springframework.batch.core.JobParametersInvalidException;
import org.springframework.batch.core.launch.JobInstanceAlreadyExistsException;
import org.springframework.batch.core.launch.JobOperator;
import org.springframework.batch.core.launch.NoSuchJobException;

public class JMXJobRunner {

    private JobOperator operator;

    public void runJob(String name) throws NoSuchJobException,
                                           JobInstanceAlreadyExistsException,
                                           JobParametersInvalidException {
        operator.start(name, null);
    }
    public void setOperator(JobOperator operator) {
        this.operator = operator;
    }
}

In Listing 5-12, you use the JobOperator.start method to launch a job with the name provided and no parameters; the job is configured within the previously loaded ApplicationContext. With the JMXJobRunner and Batch classes written, the only thing left is to wire them up with Spring. All of the configuration for these elements is in launch-context.xml, as shown in Listing 5-13.

<?xml version="1.0" encoding="UTF-8"?>
<beans:beans xmlns:beans="http://www.springframework.org/schema/beans"
    xmlns="http://www.springframework.org/schema/batch"
    xmlns:p="http://www.springframework.org/schema/p"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.springframework.org/schema/beans
        http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
        http://www.springframework.org/schema/batch
        http://www.springframework.org/schema/batch/spring-batch-2.1.xsd">

    <beans:bean id="jobOperator"
      class="org.springframework.batch.core.launch.support.SimpleJobOperator"
      p:jobLauncher-ref="jobLauncher" p:jobExplorer-ref="jobExplorer"
      p:jobRepository-ref="jobRepository" p:jobRegistry-ref="jobRegistry" />

    <beans:bean id="jobExplorer"
class="org.springframework.batch.core.explore.support.JobExplorerFactoryBean"
        p:dataSource-ref="dataSource" />

    <beans:bean id="taskExecutor"
        class="org.springframework.core.task.SimpleAsyncTaskExecutor" />

    <beans:bean id="jobLauncher"
     class="org.springframework.batch.core.launch.support.SimpleJobLauncher">
        <beans:property name="jobRepository" ref="jobRepository" />
        <beans:property name="taskExecutor" ref="taskExecutor" />
    </beans:bean>

    <job-repository id="jobRepository"
        data-source="dataSource" transaction-manager="transactionManager" />

<beans:bean id="jobRegistry"
class="org.springframework.batch.core.configuration.support.MapJobRegistry" />

    <beans:bean
class="org.springframework.batch.core.configuration.support.AutomaticJobRegistrar">
        <beans:property name="applicationContextFactories">
            <beans:bean
class="org.springframework.batch.core.configuration.support.
ClasspathXmlApplicationContextsFactoryBean">
                <beans:property name="resources"
                    value="classpath*:/jobs/helloWorld.xml" />
            </beans:bean>
        </beans:property>
        <beans:property name="jobLoader">
            <beans:bean
                class="org.springframework.batch.core.configuration.support.DefaultJobLoader">
                <beans:property name="jobRegistry" ref="jobRegistry" />
            </beans:bean>
        </beans:property>
    </beans:bean>

    <beans:bean id="jobRunner"
        class="com.apress.springbatch.chapter5.JMXJobRunnerImpl"
        p:operator-ref="jobOperator" />

    <beans:bean id="exporter"
        class="org.springframework.jmx.export.MBeanExporter"
        lazy-init="false">
        <beans:property name="beans">
            <map>
                <entry key="bean:name=myJobRunner" value-ref="jobRunner" />
            </map>
        </beans:property>
        <beans:property name="assembler" ref="assembler" />
    </beans:bean>

    <beans:bean id="assembler"
        class="org.springframework.jmx.export.assembler.
        InterfaceBasedMBeanInfoAssembler">
        <beans:property name="managedInterfaces">
            <list>
                <value>com.apress.springbatch.chapter5.JMXJobRunner
                </value>
            </list>
        </beans:property>
    </beans:bean>

    <beans:bean id="registry"
        class="org.springframework.remoting.rmi.RmiRegistryFactoryBean">
        <beans:property name="port" value="1099" />
    </beans:bean>

<beans:bean id="dataSource"
        class="org.apache.commons.dbcp.BasicDataSource">
        <beans:property name="driverClassName"
            value="${batch.jdbc.driver}" />
        <beans:property name="url" value="${batch.jdbc.url}" />
        <beans:property name="username" value="${batch.jdbc.user}" />
        <beans:property name="password" value="${batch.jdbc.password}" />
    </beans:bean>

<beans:bean id="transactionManager"
    class="org.springframework.jdbc.datasource.DataSourceTransactionManager"
    lazy-init="true">
        <beans:property name="dataSource" ref="dataSource" />
    </beans:bean>

    <beans:bean id="placeholderProperties"
        class="org.springframework.beans.factory.config.
        PropertyPlaceholderConfigurer">
        <beans:property name="location" value="classpath:batch.properties" />
        <beans:property name="systemPropertiesModeName"
            value="SYSTEM_PROPERTIES_MODE_OVERRIDE" />
        <beans:property name="ignoreUnresolvablePlaceholders"
            value="true" />
        <beans:property name="order" value="1" />
    </beans:bean>
</beans:beans>

This launch-context.xml file has a lot going on, so let's take it from the top. In order for the JMXJobLauncher to be able to start a job, you need a reference to a JobOperator. The first bean in this file is that configuration. SimpleJobOperator is the only implementation of the JobOperator interface provided by the Spring Batch framework. You configure it to have access to the JobExplorer, JobLauncher, JobRepository, and JobRegistry. Given what the JobOperator can do, these dependencies are all needed.

The JobExplorer is next, to provide read-only access to the JobRepository for many of the objects in this configuration. After the JobExplorer is a TaskExecutor configuration along with the JobLauncher used by the JobOperator. The JobLauncher does the work of starting the job and is managed by the JobOperator for your environment. You configure the JobRepository next; as discussed, this is used by Spring Batch to maintain the state of your jobs.

The JobRegistry is the next bean configured. Spring Batch provides the ability to register a collection of jobs in a JobRegistry to be executed on demand. The JobRegistry contains all the jobs that are eligible to be run in this JVM. In the case of this configuration, you're using Spring Batch's MapJobRegistry, which is a Map of jobs available to be run. In order to populate the JobRegistry on startup, you configure an instance of AutomaticJobRegistrar. This class, as configured in Listing 5-13, reads all the jobs configured in the /jobs/helloWorldJob.xml file and loads them into the JobRegistry for future use.

The final piece from a Spring Batch perspective in this launch-context.xml file is the configuration of JMXJobLauncher itself. The rest of the configuration found in this file consists of the datasource, transaction manager, properties loader, and required elements to expose JMXJobLauncher as an MBean.

With all of the configuration and coding complete, you can now run the main class, Batch, and look at the beans exposed via JMX with the JConsole application provided by the JDK. To launch the Batch program, you need to make one last tweak, however. When you create a shell project by using Spring Batch's simple-cli-archetype, the cli stands for command line interface. The Project Object Model (POM) in this project is preconfigured to create a jar file, with CommandLineJobRunner defined as the main class by default. For this example, you update the POM to use the Batch class from Listing 5-11 as the main method for your jar. Listing 5-14 shows the snippet that needs to be updated.

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-jar-plugin</artifactId>
    <configuration>
        <archive>
            <index>false</index>
            <manifest>
                <mainClass>com.apress.springbatch.chapter5.Batch</mainClass>
                <addClasspath>true</addClasspath>
                <classpathPrefix>lib/</classpathPrefix>
            </manifest>
            <manifestFile>
                ${project.build.outputDirectory}/META-INF/MANIFEST.MF
            </manifestFile>
        </archive>
    </configuration>
</plugin>

With the POM updated, you can use the same command you have in the past to launch the program: java –jar metadata-0.0.1-SNAPSHOT.jar.

Notice that when you run the program, the output is quite different. This time, no job runs. Instead, you see Spring bootstrap and register the job helloWorldJob from the helloWorld.xml file, as shown in Listing 5-16.

2010-12-16 21:17:41,390 DEBUG com.apress.springbatch.chapter5.Batch.main()
[org.springframework.batch.core.configuration.support.DefaultJobLoader] - <Registering job:
helloWorldJob1 from context: file:/Users/mminella/Documents/SpringBatch/Chapter5/batch-
test/target/classes/jobs/helloWorld.xml>

With the Batch process running, you view the beans exposed via JMX using Java's JConsole. JConsole is a free Java monitoring and management tool provided with the JDK. It allows you to monitor the JVM in a number of ways, including CPU utilization and memory allocation, and it lets you perform management tasks including interacting with JMX beans. When you launch JConsole, you're presented with a screen that asks you which Java process you would like to connect to, as shown in Figure 5-2.

Figure 5.2. The JConsole main screen

In this case, select the local process (you can use JConsole to administer remote Java processes as well) with the name org.codehaus.classworlds.Launcher "exec:java". This is the Java process you launched with the maven command in Listing 5-15. Clicking connect allows JConsole to connect to the JVM.

After you connect, JConsole shows you a screen like the one in Figure 5-3. At the top are six tabs: Overview, Memory, Threads, Classes, VM Summary, and MBeans. Below the tabs, JConsole lets you select the time range for which to display the overview data. Finally, there are four quadrants of data: the amount of JVM heap memory usage, the number of threads being used, the number of classes currently loaded by the JVM, and the CPU usage during the time selected. The tab you're interested in is MBeans.

Figure 5.3. Overview of the JVM

When you select the MBeans tab, you're presented with a tree navigation on the left and a main panel in the rest of the window. In Listing 5-13 you configured the bean to be in the namespace bean and have the name myJobRunner. Sure enough, Figure 5-4 shows the bean namespace in the tree navigation with a bean myJobRunner available.

Figure 5.4. JMXJobRunner exposed in JConsole

For any bean exposed, there are up to three sections: attributes that allow you to modify public attributes (which you don't have in this case); Operations, which lets you execute public methods; and Notifications, to show you any JMX notifications (messages sent from the bean to anyone listening via JMX). To run your batch job, go to Operations, as shown in Figure 5-5. There you see the only public method on JMXJobRunner: runJob. It's void and takes a single parameter. To invoke the job, all you need to do is enter the job name in the box and click Runjob.

Figure 5.5. The JMXJobRunner.runJob method exposed in JConsole

When you click the Runjob button, you see in the console in which you're currently running your Java process that the job runs, giving you the output you expect with helloWorldJob.

2010-12-17 17:06:09,444 DEBUG RMI TCP Connection(1)-192.168.1.119
[org.springframework.batch.core.scope.context.StepContextRepeatCallback] - <Chunk execution
starting: queue size=0>

Hello, World!

2010-12-17 17:06:09,450 DEBUG RMI TCP Connection(1)-192.168.1.119
[org.springframework.batch.core.step.tasklet.TaskletStep] - <Applying contribution:
[StepContribution: read=0, written=0, filtered=0, readSkips=0, writeSkips=0, processSkips=0,
exitStatus=EXECUTING]>

In this example, you wrote a job runner that you were able to expose via JMX. Other uses would be to develop a step listener that stops the job based on a given condition. In Chapter 6, you expand this example to accept parameters and use the JobOperator to stop and restart jobs programmatically.