diff --git a/spring-batch-core/src/main/java/org/springframework/batch/core/launch/support/CommandLineJobRunner.java b/spring-batch-core/src/main/java/org/springframework/batch/core/launch/support/CommandLineJobRunner.java index 35c869618..7d0648e1c 100644 --- a/spring-batch-core/src/main/java/org/springframework/batch/core/launch/support/CommandLineJobRunner.java +++ b/spring-batch-core/src/main/java/org/springframework/batch/core/launch/support/CommandLineJobRunner.java @@ -116,8 +116,7 @@ import org.springframework.util.StringUtils; */ public class CommandLineJobRunner { - protected static final Log logger = LogFactory - .getLog(CommandLineJobRunner.class); + protected static final Log logger = LogFactory.getLog(CommandLineJobRunner.class); private ExitCodeMapper exitCodeMapper = new SimpleJvmExitCodeMapper(); @@ -132,8 +131,7 @@ public class CommandLineJobRunner { /** * Injection setter for the {@link JobLauncher}. * - * @param launcher - * the launcher to set + * @param launcher the launcher to set */ public void setLauncher(JobLauncher launcher) { this.launcher = launcher; @@ -142,8 +140,7 @@ public class CommandLineJobRunner { /** * Injection setter for the {@link ExitCodeMapper}. * - * @param exitCodeMapper - * the exitCodeMapper to set + * @param exitCodeMapper the exitCodeMapper to set */ public void setExitCodeMapper(ExitCodeMapper exitCodeMapper) { this.exitCodeMapper = exitCodeMapper; @@ -157,7 +154,7 @@ public class CommandLineJobRunner { public void setSystemExiter(SystemExiter systemExitor) { this.systemExiter = systemExitor; } - + /** * Injection setter for {@link JobParametersConverter}. * @@ -179,7 +176,6 @@ public class CommandLineJobRunner { public void setJobLocator(JobLocator jobLocator) { this.jobLocator = jobLocator; } - /* * Start a job by obtaining a combined classpath using the job launcher and @@ -192,28 +188,29 @@ public class CommandLineJobRunner { try { context = new ClassPathXmlApplicationContext(jobPath); - context.getAutowireCapableBeanFactory().autowireBeanProperties( - this, AutowireCapableBeanFactory.AUTOWIRE_BY_TYPE, false); + context.getAutowireCapableBeanFactory().autowireBeanProperties(this, + AutowireCapableBeanFactory.AUTOWIRE_BY_TYPE, false); Job job; if (jobLocator != null) { job = jobLocator.getJob(jobName); - } else { + } + else { job = (Job) context.getBean(jobName); } - JobParameters jobParameters = jobParametersConverter - .getJobParameters(StringUtils - .splitArrayElementsIntoProperties(parameters, "=")); + JobParameters jobParameters = jobParametersConverter.getJobParameters(StringUtils + .splitArrayElementsIntoProperties(parameters, "=")); JobExecution jobExecution = launcher.run(job, jobParameters); - return exitCodeMapper.intValue(jobExecution.getExitStatus() - .getExitCode()); - } catch (Throwable e) { + return exitCodeMapper.intValue(jobExecution.getExitStatus().getExitCode()); + } + catch (Throwable e) { logger.error("Job Terminated in error:", e); return exitCodeMapper.intValue(ExitStatus.FAILED.getExitCode()); - } finally { - if (context!=null) { + } + finally { + if (context != null) { context.close(); } } @@ -225,28 +222,25 @@ public class CommandLineJobRunner { * such contexts. No exception are thrown from this method, rather * exceptions are logged and an integer returned through the exit status in * a {@link JvmSystemExiter} (which can be overridden by defining one in the - * Spring context). + * Spring context).
Parameters can be provided in the form key=value, + * and will be converted using the injected {@link JobParametersConverter}. * * @param args - *

- *

- *

+ *

+ *

+ *

*/ public static void main(String[] args) { CommandLineJobRunner command = new CommandLineJobRunner(); if (args.length < 2) { - logger - .error("At least 2 arguments are required: JobPath and JobName."); + logger.error("At least 2 arguments are required: JobPath and JobName."); command.exit(1); } diff --git a/spring-batch-integration/src/main/java/org/springframework/batch/integration/chunk/ChunkMessageChannelItemWriter.java b/spring-batch-integration/src/main/java/org/springframework/batch/integration/chunk/ChunkMessageChannelItemWriter.java index 18dab17fd..7be2807d1 100644 --- a/spring-batch-integration/src/main/java/org/springframework/batch/integration/chunk/ChunkMessageChannelItemWriter.java +++ b/spring-batch-integration/src/main/java/org/springframework/batch/integration/chunk/ChunkMessageChannelItemWriter.java @@ -153,7 +153,7 @@ public class ChunkMessageChannelItemWriter extends StepExecutionListenerSupport private boolean waitForResults() { // TODO: cumulative timeout, or throw an exception? int count = 0; - int maxCount = 10; + int maxCount = 40; while (localState.getExpecting() > 0 && count++ < maxCount) { getNextResult(100); } diff --git a/src/site/apt/index.apt b/src/site/apt/index.apt index eef063047..e812302af 100644 --- a/src/site/apt/index.apt +++ b/src/site/apt/index.apt @@ -21,7 +21,7 @@ Introduction [images/ExecutionEnvironment.png] Spring Batch Architecture showing Infrastructure and Execution Layers. Potential execution strategy implementations support different platforms and end-user goals from the same blocks of business logic in the Application Layer. - The initial release provides an Infrastructure layer in the form of low level tools. There is also a simple execution environment, using the infrastructure in its implementation. The execution environment provides robust features for traceability and management of the batch lifecycle. A key goal is that the management of the batch process (locating a job and its input, starting, scheduling, restarting, and finally processing to created results) should be as easy as possible for developers. + Spring Batch provides an Infrastructure layer in the form of low level tools. There is also a simple execution environment, using the infrastructure in its implementation. The execution environment provides robust features for traceability and management of the batch lifecycle. A key goal is that the management of the batch process (locating a job and its input, starting, scheduling, restarting, and finally processing to created results) should be as easy as possible for developers. The Infrastructure provides the ability to batch operations together, and to retry an piece of work if there is an exception. Both requirements have a transactional flavour, and similar concepts are relevant (propagation, synchronisation). They also both lend themselves to the template programming model common in Spring, c.f. <<>>, <<>>, <<>>. @@ -35,11 +35,15 @@ Introduction * Roadmap - Once the framework is released it can be used immediately to simplify batch optimisations and automatic retries. The framework is oriented around application developers not needing to know any details of the framework - there are a few application developer interfaces that can be used for convenient construction of data processing pipelines, but apart from that we support as close to a POJO programming model as is practical. This is similar to the approach taken in Spring Core in the area of DAO implementation. - - A partitioned step execution strategy is also being developed that will provide alternate scaling solutions. This will provide more advanced technical services and features to enable extremely high-volume and high performance batch jobs though proven optimization and partitioning techniques. Proven scaling techniques will be provided as partitioned strategies allowing users to spread the load across a pool of clustered J2EE application servers. There are also discussions to leverage grid technologies as an alternate scaling solution. + The current production release version is specified {{{downloads.html}here}}, and links are also provided to the latest development work. - Matt Welsh's work shows that {{{http://www.eecs.harvard.edu/~mdw/proj/seda/}SEDA}} has enormous benefits over more rigid processing architectures, and messaging environments give us a lot of resilience out of the box. So we also want to provide a more SEDA flavoured execution environments, as well as supporting the more traditional ETL style approach. There might be a tie in with Mule and/or other ESB tools here, giving the benefit of a very scalable architecture, where the choice of transport and distribution strategy can be made as late as possible. The same application code could be used in principle for a standalone tool processing a small amount of data, and a massive enterprise-scale bulk-processing engine. + The framework is oriented around application developers not needing to know any details of the framework - there are a few application developer interfaces that can be used for convenient construction of data processing pipelines, but apart from that we support as close to a POJO programming model as is practical. This is similar to the approach taken in Spring Core in the area of DAO implementation. + + Spring Batch version 1.x was targeted at Java 1.4 and single-process, possibly multi-threaded execution. Spring Batch 2.0 will be a Java 5 only release, using all available language features with no compromises for backward compatibility with Java 2. We think this will provide a significantly improved programming model for batch application developers. Spring Batch 2.0 will also introduce new features enabling an application to scale to multiple processes. + + Framework tools for scaling to multiple processes are being developed in a parallel project hosted inside Spring Batch. These will provide more advanced technical services and features to enable extremely high-volume and high performance batch jobs though proven optimization and clustering techniques. Proven scaling techniques will be provided as strategies allowing users to spread the load across a pool of clustered servers. There are also discussions to leverage grid technologies as a scaling solution. These features are targeted for Spring Batch version 2.0. + + Matt Welsh's work shows that {{{http://www.eecs.harvard.edu/~mdw/proj/seda/}SEDA}} has enormous benefits over more rigid processing architectures, and messaging environments give us a lot of resilience out of the box. So we also want to enable a more SEDA flavoured execution environments, as well as supporting the more traditional ETL style approach. The key to unlocking the programming model is {{{http://www.springframework.org/projects/spring-integration}Spring Integration}}, where the choice of transport and distribution strategy can be made as late as possible. The key to the runtime requirements of deployment and manageability is going to be with the {{{http://www.springsource.com/products/suite/applicationplatform}SpringSource Application Platform}}. The same application code could be used in principle for a standalone tool processing a small amount of data, and a massive enterprise-scale bulk-processing engine. * Background