Job Controllers
Job Controllers as the name implies, define, how the job should be written and how it will be
executed (controlled) in runtime. This is the important component in the framework and this is the component
developer really care and work with.
Job Controllers define their own logic to write a batch job and explains the way this
logic will be executed in the runtime. Along with the controller logic, they support the
admin applications by providing the useful information to monitor and manage.
They provide set of interfaces for developers to implement and put their business logic in.
They provide the way to configure the batch job in the job configuration. As of now framework,
provides two controllers names as PoolJobController and BasicJobController.
PoolJobController
This controller provides the logic revolves around the job pool, job loader and job processor(s).
The way this logic works is, there will be a designated pool for each batch job, there
will be a loader loads all the
data needs to be processed into the pool, there will be one ore more than one
job processor(s) picks the data from the pool and process them. This controller provides
three interfaces to implement the batch job, JobPool which holds the job data, PoolJobLoader which
loads the job data into the JobPool and PoolJobProcessor which picks the data from the pool
and process them.
For better and quick understanding, lets take a task of writing a batch job "process-integers" which actually loads 10 integer objects into the pool and process them
by using 3 job processors.
Controlling the Logging
Logging is one of the very important activity in writing the batch jobs. This information
will be very useful when trying to debug the failures of a batch job. Batch Framework comes with a
logging manager which takes care of all the logging for the batch jobs. Following is the default logging configuration
from the framework configuration (framework-config.xml) file. In the rest of this section, we will
explore this configuration.
<framework-logging-config
framework-logging-level="DEBUG"
job-logging-directory="/batchserver/logs"
job-base-package-name="com.mycompany.batch"
job-logging-level="INFO"/>
Framework does its own logging to a "batch_framework.log" file in the directory given in
the "job-logging-directory" attribute in the configuration. Initially, it will be set to
"/batchserver/logs". This can changed to wherever you like the logging needs to be done.
The default logging level for the all the framework information will be "DEBUG" which is
specified in the attribute "framework-logging-level".
Using a single logger to all the jobs is not enough for everyone. There could be scenarios that
logging level needs to be controlled for each batch job. To satisfy those requirements
framework provides the flexibility to control the logging level of each batch job. This can be
done by declaring the additional loggers in the job configuration. Following job configuration
defines it own loggers to control the logging.
Along with these facilities, framework provides the controlling of the logging level
of every job at the runtime through management and monitoring applications.
