From a9d1ac3018bc226dd141275369683aca8fc6ca80 Mon Sep 17 00:00:00 2001 From: dhgarrette Date: Wed, 4 Feb 2009 16:50:44 +0000 Subject: [PATCH] BATCH-1056: minor fixes --- docs/src/site/docbook/reference/repeat.xml | 142 +++++++----------- docs/src/site/docbook/reference/retry.xml | 91 ++++++------ docs/src/site/docbook/reference/step.xml | 163 +++++++++++---------- 3 files changed, 187 insertions(+), 209 deletions(-) diff --git a/docs/src/site/docbook/reference/repeat.xml b/docs/src/site/docbook/reference/repeat.xml index ff53841d7..ca0182375 100644 --- a/docs/src/site/docbook/reference/repeat.xml +++ b/docs/src/site/docbook/reference/repeat.xml @@ -8,38 +8,39 @@ RepeatTemplate Batch processing is about repetitive actions - either as a simple - optimisation, or as part of a job. To strategie and generalise the - repetition, and provide what amounts to an iterator framework, Spring - Batch has the RepeatOperations interface. The - RepeatOperations interface looks like this: + optimisation, or as part of a job. To strategize and generalize the + repetition as well as to provide what amounts to an iterator framework, + Spring Batch has the RepeatOperations interface. + The RepeatOperations interface looks like + this: public interface RepeatOperations { - ExitStatus iterate(RepeatCallback callback) throws RepeatException; + RepeatStatus iterate(RepeatCallback callback) throws RepeatException; -}where the callback is a simple interface that allows you to - insert some business logic to be repeated +}The callback is a simple interface that allows you to insert + some business logic to be repeated: public interface RepeatCallback { - ExitStatus doInIteration(RepeatContext context) throws Exception; + RepeatStatus doInIteration(RepeatContext context) throws Exception; -}The callback is executed repeatedly, until the - implementation decides that the iteration should end. The return value in - these interfaces is a special form of extendable enumeration (not a true - enumeration because users are free to create new values). An - ExitStatus is immutable and conveys information to - the caller of the repeat operations about whether there is any more work - to do. Generally speaking, implementations of +}The callback is executed repeatedly until the implementation + decides that the iteration should end. The return value in these + interfaces is an enumeration that can either be + RepeatStatus.CONTINUABLE or + RepeatStatus.FINISHED. A RepeatStatus + conveys information to the caller of the repeat operations about whether + there is any more work to do. Generally speaking, implementations of RepeatOperations should inspect the - ExitStatus and use it as part of the decision to + RepeatStatus and use it as part of the decision to end the iteration. Any callback that wishes to signal to the caller that there is no more work to do can return - ExitStatus.FINISHED. + RepeatStatus.FINISHED. The simplest general purpose implementation of RepeatOperations is - RepeatTemplate. It could be used like this + RepeatTemplate. It could be used like this: RepeatTemplate template = new RepeatTemplate(); @@ -54,13 +55,13 @@ template.iterate(new RepeatCallback() { }); - In the example we return ExitStatus.CONTINUABLE to show - that there is more work to do. The callback can also return + In the example we return RepeatStatus.CONTINUABLE to + show that there is more work to do. The callback can also return ExitStatus.FINISHED if it wants to signal to the caller that there is no more work to do. Some iterations can be terminated by considerations intrinsic to the work being done in the callback, others - are effectively infinite loops as far as the callback is concerned, and - the completion decision is delegated to an external policy as in the case + are effectively infinite loops as far as the callback is concerned and the + completion decision is delegated to an external policy as in the case above.
@@ -82,77 +83,44 @@ template.iterate(new RepeatCallback() {
- ExitStatus + RepeatStatus - ExitStatus is used by Spring Batch to - indicate whether processing has finished, and if so whether or not is - was successful. It is also used to carry textual information about the - end state of a batch or iteration, in the form of an exit code and a - description of the status in freeform text. These are the properties of - an ExitStatus: + RepeatStatus is an enumeration used by + Spring Batch to indicate whether processing has finished. These are + possible RepeatStatus values: ExitStatus properties - + - Property Name + Value - Type - - Description + Description - continuable + CONTINUABLE - boolean - - true if there is more work to do + There is more work to do. - exitCode + FINISHED - String - - Short code describing the exit status, e.g. CONTINUABLE, - FINISHED, FAILED - - - - exitDescription - - String - - Long description of the exit status, could be a stack - trace for example. + No more repetitions should take place.
- ExitStatus values are designed to be - flexible, so that they can be created with any code and description the - user needs. Spring Batch comes with some standard values out of the box, - to support common use cases, but users are free to create their own - values, as long as the semantics of the continuable - property are honoured. - - ExitStatus values can also be combined with various operators - built into the class as methods. You can add an exit code, or - description, or combine the continuable values with logical AND using - methods in ExitStatus. You can also combine two ExitStatus values with - the and method taking ExitStatus as a parameter. The effect of this is - to do a logical AND on the continuable flag, concatenate the - descriptions and replace the exit code with the new value, as long as - the result is continuable, or the input is not continuable. This has the - effect of maintaining the semantics of the continuable flag, but not - making any "surprising" changes to the exit code (e.g. it never becomes - CONTINUABLE when it was already FINISHED, unless someone does something - wilful, like pass in a value that is not continuable, but with a code of - CONTINUABLE). + RepeatStatus values can also be combined + with a logical AND operation using the and() + method in RepeatStatus. The effect of this is to + do a logical AND on the continuable flag. In other words, if either + status is FINISHED, then the result will be + FINISHED.
@@ -167,22 +135,22 @@ template.iterate(new RepeatCallback() { current policy to create a RepeatContext and pass that in to the RepeatCallback at every stage in the iteration. After a callback completes its - doInIteration the + doInIteration, the RepeatTemplate has to make a call to the CompletionPolicy to ask it to update its state - (which will be stored in the RepeatContext), then + (which will be stored in the RepeatContext). Then it asks the policy if the iteration is complete. Spring Batch provides some simple general purpose implementations of - CompletionPolicy, for example the - SimpleCompletionPolicy used in the example above. - The SimpleCompletionPolicy just allows an execution - up to a fixed number of times (with ExitStatus.FINISHED + CompletionPolicy. The + SimpleCompletionPolicy just allows an execution up + to a fixed number of times (with RepeatStatus.FINISHED forcing early completion at any time). Users might need to implement their own completion policies for more - complicated decisions, e.g. a batch processing window that prevents batch - jobs from executing once the online systems are in use. + complicated decisions. For example, a batch processing window that + prevents batch jobs from executing once the online systems are in use + would require a custom policy.
@@ -227,7 +195,7 @@ template.iterate(new RepeatCallback() { interface. The RepeatTemplate allows users to register RepeatListeners, and they will be given callbacks with the RepeatContext and - ExitStatus where available during the + RepeatStatus where available during the iteration. The interface looks like this: @@ -235,7 +203,7 @@ template.iterate(new RepeatCallback() { public interface RepeatListener { void before(RepeatContext context); - void after(RepeatContext context, ExitStatus result); + void after(RepeatContext context, RepeatStatus result); void open(RepeatContext context); @@ -245,13 +213,13 @@ template.iterate(new RepeatCallback() { } The open and close callbacks come before and after the entire - iteration, and before, - after and onError apply - to the individual RepeatCallback calls. + iteration. before, after + and onError apply to the individual + RepeatCallback calls. Note that when there is more than one listener, they are in a list, so there is an order. In this case open and - before are called in the same order, and + before are called in the same order while after, onError and close are called in reverse order.
@@ -262,7 +230,7 @@ template.iterate(new RepeatCallback() { Implementations of RepeatOperations are not restricted to executing the callback sequentially. It is quite important that some implementations are able to execute their callbacks in parallel. - To this end Spring Batch provides the + To this end, Spring Batch provides the TaskExecutorRepeatTemplate, which uses the Spring TaskExecutor strategy to run the RepeatCallback. The default is to use a diff --git a/docs/src/site/docbook/reference/retry.xml b/docs/src/site/docbook/reference/retry.xml index 70864f40b..2fe8c0f68 100644 --- a/docs/src/site/docbook/reference/retry.xml +++ b/docs/src/site/docbook/reference/retry.xml @@ -10,12 +10,13 @@ To make processing more robust and less prone to failure, sometimes it helps to automatically retry a failed operation in case it might succeed on a subsequent attempt. Errors that are susceptible to this kind - of treatment are transient in nature, for example a remote call to a web - service or RMI service that fails because of a network glitch, or a - DeadLockLoserException in a database update. To - automate the retry of such operations Spring Batch has the - RetryOperations strategy. The - RetryOperations interface looks like this: + of treatment are transient in nature. For example a remote call to a web + service or RMI service that fails because of a network glitch or a + DeadLockLoserException in a database update may + resolve themselves after a short wait. To automate the retry of such + operations Spring Batch has the RetryOperations + strategy. The RetryOperations interface looks like + this: public interface RetryOperations { @@ -30,8 +31,8 @@ <T> T execute(RetryCallback<T> retryCallback, RecoveryCallback<T> recoveryCallback, RetryState retryState) throws Exception; -}where the basic callback is a simple interface that allows - you to insert some business logic to be retried +}The basic callback is a simple interface that allows you to + insert some business logic to be retried: public interface RetryCallback<T> { @@ -86,9 +87,9 @@ Foo result = template.execute(new RetryCallback<Foo>() { When a retry is exhausted the RetryOperations can pass control to a different - callback, the RetryCallback. To use this feature - clients just pass in the callbacks together to the same method, for - example: + callback, the RecoveryCallback. To use this + feature clients just pass in the callbacks together to the same method, + for example: Foo foo = template.execute(new RetryCallback<Foo>() { public Foo doWithRetry(RetryContext context) { @@ -106,7 +107,7 @@ Foo result = template.execute(new RetryCallback<Foo>() {
Stateless Retry - In the simplest case a retry is just a while loop - the + In the simplest case, a retry is just a while loop: the RetryTemplate can just keep trying until it either succeeds or fails. The RetryContext contains some state to determine whether to retry or abort, but this @@ -123,12 +124,12 @@ Foo result = template.execute(new RetryCallback<Foo>() { Stateful Retry Where the failure has caused a transactional resource to become - invalid there are some special considerations. This does not apply to a - simple remote call because there was no transactional resource - (usually), but it does sometimes apply to a database update, especially - when using Hibernate. In this case it only makes sense to rethrow the - exception that called the failure immediately, so that the transaction - can roll back, and we can start a new valid one. + invalid, there are some special considerations. This does not apply to a + simple remote call because there is no transactional resource (usually), + but it does sometimes apply to a database update, especially when using + Hibernate. In this case it only makes sense to rethrow the exception + that called the failure immediately so that the transaction can roll + back and we can start a new valid one. In these cases a stateless retry is not good enough because the re-throw and roll back necessarily involve leaving the @@ -142,20 +143,21 @@ Foo result = template.execute(new RetryCallback<Foo>() { Map. Advanced usage with multiple processes in a clustered environment might also consider implementing the RetryContextCache with a cluster cache of some - sort (even in a clustered environment this might be overkill). + sort (though, even in a clustered environment this might be + overkill). Part of the responsibility of the - RetryOperations is to recognise the failed + RetryOperations is to recognize the failed operations when they come back in a new execution (and usually wrapped in a new transaction). To facilitate this, Spring Batch provides the RetryState abstraction. This works in conjunction with a special execute methods in the RetryOperations. - The way the failed operations are recognised is by identifying the - state across multiple invocations of the retry. To identify the state - the user can provide an RetryState object, and - this is responsible for returning a unique key identifying the item. The + The way the failed operations are recognized is by identifying the + state across multiple invocations of the retry. To identify the state, + the user can provide an RetryState object that is + responsible for returning a unique key identifying the item. The identifier is used as a key in the RetryContextCache. @@ -176,9 +178,8 @@ Foo result = template.execute(new RetryCallback<Foo>() { RetryOperations. The decision to retry or not is actually delegated to a regular - retry policy, so the usual concerns about limits and timeouts can be - injected through the RetryPolicy (see - below). + RetryPolicy, so the usual concerns about limits + and timeouts can be injected there (see below).
@@ -199,8 +200,8 @@ Foo result = template.execute(new RetryCallback<Foo>() { another attempt can be made. If another attempt cannot be made (e.g. a limit is reached or a timeout is detected) then the policy is also responsible for handling the exhausted state. Simple implementations will - just throw RetryExhaustedException, and any - enclosing transaction will be rolled back. More sophisticated + just throw RetryExhaustedException which will cause + any enclosing transaction to be rolled back. More sophisticated implementations might attempt to take some recovery action, in which case the transaction can remain intact. @@ -210,9 +211,8 @@ Foo result = template.execute(new RetryCallback<Foo>() { doesn't help to retry it. So don't retry on all exception types - try to focus on only those exceptions that you expect to be retryable. It's not usually harmful to the business logic to retry more aggressively, but - it's wasteful because if a failure is deterministic there could be a - very tight loop retrying something that you know in advance is - fatal. + it's wasteful because if a failure is deterministic there will be time + spent retrying something that you know in advance is fatal. Spring Batch provides some simple general purpose implementations of @@ -224,8 +224,8 @@ Foo result = template.execute(new RetryCallback<Foo>() { The SimpleRetryPolicy just allows a retry on any of a named list of exception types, up to a fixed number of times. It also has a list of "fatal" exceptions that should never be retried, and - this list overrides the retryable list, so it can be used to give finer - control over the retry behaviour, e.g. + this list overrides the retryable list so that it can be used to give + finer control over the retry behavior: SimpleRetryPolicy policy = new SimpleRetryPolicy(5); // Retry on all exceptions (this is the default) @@ -244,7 +244,7 @@ template.execute(new RetryCallback<Foo>() { There is also a more flexible implementation called ExceptionClassifierRetryPolicy, which allows the - user to configure different retry behaviour for an arbitrary set of + user to configure different retry behavior for an arbitrary set of excecption types though the ExceptionClassifier abstraction. The policy works by calling on the classifier to convert an exception into a delegate RetryPolicy, so for @@ -252,8 +252,9 @@ template.execute(new RetryCallback<Foo>() { another by mapping it to a different policy. Users might need to implement their own retry policies for more - customized decisions, e.g. if there is a well-known solution-specific - classification of exceptions into retryable and not retryable. + customized decisions. For instance, if there is a well-known, + solution-specific, classification of exceptions into retryable and not + retryable.
@@ -306,16 +307,16 @@ template.execute(new RetryCallback<Foo>() { } The open and close callbacks come before and after the entire - retry in the simplest case, and onError applies - to the individual RetryCallback calls. The close - method might also receive a Throwable, if there has - been an error it is the last one thrown by the - RetryCallback. + retry in the simplest case and onError applies to + the individual RetryCallback calls. The + close method might also receive a + Throwable; if there has been an error it is the + last one thrown by the RetryCallback. Note that when there is more than one listener, they are in a list, - so there is an order. In this case open is called - in the same order, and onError and - close are called in reverse order. + so there is an order. In this case open will be + called in the same order while onError and + close will be called in reverse order.
diff --git a/docs/src/site/docbook/reference/step.xml b/docs/src/site/docbook/reference/step.xml index 28e76efe7..96103f2b2 100644 --- a/docs/src/site/docbook/reference/step.xml +++ b/docs/src/site/docbook/reference/step.xml @@ -32,7 +32,7 @@
Chunk-Oriented Processing - Spring Batch uses a 'Chunk Oriented' processing style within it's + Spring Batch uses a 'Chunk Oriented' processing style within its most common implementation. Chunk oriented processing refers to reading the data one at a time, and creating 'chunks' that will be written out, within a transaction boundary. One item is read in from an @@ -61,7 +61,8 @@ List items = new Arraylist(); for(int i = 0; i < commitInterval; i++){ - Object processedItem = itemProcessor.process(itemReader.read()); + Object item = itemReader.read() + Object processedItem = itemProcessor.process(item); items.add(processedItem); } itemWriter.write(items); @@ -120,8 +121,9 @@ It should be noted that, job-repository defaults to "jobRepository" and transaction-manager defaults to "transactionManger". - Furthermore, the ItemProcessor is not required, since the item could be - directly passed from the reader to the writer. + Furthermore, the ItemProcessor is optional, not + required, since the item could be directly passed from the reader to the + writer.
@@ -130,13 +132,14 @@ As mentioned above, a step reads in and writes out items, periodically committing using the supplied PlatformTransactionManager. With a - commit-interval of 1, it will commit after writing only one item. This - is less than ideal in many situations, since beginning and committing a - transaction is expensive. Ideally, it is preferable to process as many - items as possible in each transaction, which is completely dependent - upon the type of data being processed and the resources with which the - step is interacting. For this reason, the number of items that are - processed within a commit can be configured. + commit-interval of 1, it will commit after writing each individual item. + This is less than ideal in many situations, since beginning and + committing a transaction is expensive. Ideally, it is preferable to + process as many items as possible in each transaction, which is + completely dependent upon the type of data being processed and the + resources with which the step is interacting. For this reason, the + number of items that are processed within a commit can be + configured. <job id="sampleJob"> @@ -168,14 +171,15 @@ Setting a StartLimit There are many scenarios where you may want to control the - number of times a Step may be started. An - example is a Step that may be run only once, - usually because it invalidates some resource that must be fixed - manually before it can be run again. This is configurable on the step - level, since different steps have different requirements. One Step - that may only be executed once can exist as part of the same - Job as Step that can be - run infinitely. Below is an example start limit configuration: + number of times a Step may be started. For + example, a particular Step might need to be + configured so that it only runs once because it invalidates some + resource that must be fixed manually before it can be run again. This + is configurable on the step level, since different steps may have + different requirements. A Step that may only be + executed once can exist as part of the same Job + as a Step that can be run infinitely. Below is + an example start limit configuration: <step name="step1"> @@ -323,7 +327,7 @@ playerSummarization is not start, and the job is immediately killed, since this is the third execution of playerSummarization, - and it's limit is only 2. The limit must either be raised, or the + and its limit is only 2. The limit must either be raised, or the Job must be executed as a new JobInstance. @@ -361,15 +365,15 @@ FlatFileParseException is thrown, it will be skipped and counted against the total skip limit of 10. It should be noted that any failures encountered while reading will not count against - the commit interval. In other words, the commit interval is only - incremented on writes (regardless of success or failure). + the skip limit. In other words, the skip limit is only incremented on + writes (regardless of success or failure).
One problem with the example above is that any other exception besides a FlatFileParseException will cause the Job to fail. In certain scenarios this may be the - correct behaviour, however, in certain scenarios it may be easier to + correct behavior. However, in other scenarios it may be easier to identify which exceptions should cause failure and skip everything else: <step name="step1"> @@ -398,8 +402,8 @@ In most cases you want an exception to cause either a skip or Step failure. However, not all exceptions are deterministic. If a FlatFileParseException is - encountered while reading, it will always be thrown for that record. - Resetting the ItemReader will not help. However, + encountered while reading, it will always be thrown for that record; + resetting the ItemReader will not help. However, for other exceptions, such as a DeadlockLoserDataAccessException, which indicates that the current process has attempted to update a record that another @@ -438,7 +442,8 @@ the Step can be configured with a list of exceptions that should not cause rollback. The transaction-attribute attribute is a comma-separated list. Prefixing a class name with the "+" - symbol will indicate that exception should not cause rollback. + symbol will indicate that that exception should not cause + rollback. <step name="step1"> @@ -450,8 +455,8 @@ Transaction attributes can be used to control multiple other - settings such as isolation and propagation behaviour. More information - on setting transaction attributes can be found in the spring core + settings such as isolation and propagation behavior. More information on + setting transaction attributes can be found in the spring core documentation.
@@ -483,21 +488,21 @@ The step has to take care of ItemStream callbacks at the necessary points in its lifecycle. (for more - information on the ItemStream interface, please refer to ) This is vital if a step fails, and might need - to be restarted, because the ItemStream interface - is where the step gets the information it needs about persistent state - between executions. + information on the ItemStream interface, please + refer to ) This is vital if a step fails, + and might need to be restarted, because the + ItemStream interface is where the step gets the + information it needs about persistent state between executions. If the ItemReader, ItemProcessor, or ItemWriter itself implements the ItemStream interface, then these will be registered automatically. Any other streams need to be registered - separately. This is often the case where there are indirect - dependencies, like delegates being injected into the reader and writer. - To a stream it can be injected into the Step - through the 'streams' element, as illustrated below: + separately. This is often the case where there are indirect dependencies + such as delegates being injected into the reader and writer. A stream + can be registered on the Step through the + 'streams' element, as illustrated below: <step name="step1"> @@ -526,11 +531,11 @@ ItemStream, but both of its delegates are. Therefore, both delegate writers must be explicitly registered as streams in order for the framework to handle them correctly. The - ItemReader does not need to explicitly registered - as a stream because it is a direct property of the + ItemReader does not need to be explicitly + registered as a stream because it is a direct property of the Step. The step will now be restartable and the - state of the reader and writer will be correctly persisted in case of a - failure. + state of the reader and writer will be correctly persisted in the event + of a failure.
@@ -560,7 +565,7 @@ In addition to the StepListener interfaces, - annotations are provided address the same concerns. + annotations are provided to address the same concerns.
StepExecutionListener @@ -763,9 +768,10 @@
SkipListener - Both ItemReadListener and - ItemWriteListner provide a mechanism for being - notified of errors, but neither one will inform you that a record has + ItemReadListener, + ItemProcessListener, and + ItemWriteListner all provide mechanisms for + being notified of errors, but none will inform you that a record has actually been skipped. onWriteError, for example, will be called even if an item is retried and successful. For this reason, there is a separate interface for tracking skipped @@ -776,9 +782,9 @@ void onSkipInRead(Throwable t); - void onSkipInWrite(S item, Throwable t); - void onSkipInProcess(T item, Throwable t); + + void onSkipInWrite(S item, Throwable t); } @@ -814,8 +820,8 @@ SkipListener is to log out a skipped item, so that another batch process or even human process can be used to evaluate and fix the issue leading to the skip. Because there are - many cases in which the original trasaction may be rolledback, - Spring Batch makes two garantees: + many cases in which the original transaction may be rolled back, + Spring Batch makes two guarantees: @@ -863,8 +869,8 @@ - TaskletStep will automatically register the tasklet as - StepExecutionListener if it implements this + TaskletStep will automatically register the + tasklet as StepListener if it implements this interface @@ -896,7 +902,7 @@ Example Tasklet implementation Many batch jobs contain steps that must be done before the main - processing begins in order to set up various resources, or after + processing begins in order to set up various resources or after processing has completed to cleanup those resources. In the case of a job that works heavily with files, it is often necessary to delete certain files locally after they have been uploaded successfully to @@ -962,8 +968,8 @@ With the ability to group steps together within an owning job, comes the need to be able to control how the job 'flows' from one step to another. The failure of a Step doesn't necessarily - mean that the Job should fail. Further, there may - be more than one type of 'success', which determines which + mean that the Job should fail. Furthermore, there + may be more than one type of 'success', which determines which Step should be executed next. Depending upon how a group of Steps is configured, certain steps may not even be processed at all. @@ -1082,7 +1088,7 @@ ExitStatus. BatchStatus is an enumeration that is a property of both JobExecution and - StepExecution, and is used by the framework to + StepExecution and is used by the framework to record the status of a Job or Step. It can be one of the following values: COMPLETED, STARTING, STARTED, FAILED, STOPPING, STOPPED, or UNKNOWN. @@ -1098,18 +1104,19 @@ At first glance, it would appear that the 'on' attribute references the BatchStatus of the - Step it belongs to. However, it references the - ExitStatus of the Step. - As the name implies, ExitStatus represents the - status of a Step after it finishes execution. - More specifically, the 'next' element above references the + Step to which it belongs. However, it + references the ExitStatus of the + Step. As the name implies, + ExitStatus represents the status of a + Step after it finishes execution. More + specifically, the 'next' element above references the ExitCode of the ExitStatus. To write it in English, it says: "go to stepB if the exit code is FAILED". By default, the exit code is always the same as the BatchStatus for the Step, which is why the entry above works. However, what if the exit code needs to be different? A good example comes from the skip sample - job, within the samples project: + job within the samples project: <step name="step1"> @@ -1138,7 +1145,7 @@ - The above configuration will work, however, something needs to + The above configuration will work. However, something needs to change the exit code based on the condition of the execution having skipped records: @@ -1160,8 +1167,8 @@ that first checks to make sure the Step was successful, and next if the skip count on the StepExecution is higher than 0. If both - conditions are met, a new ExitStatus with an exit code of "COMPLETED - WITH SKIPS" is returned. + conditions are met, a new ExitStatus with an + exit code of "COMPLETED WITH SKIPS" is returned.
@@ -1199,8 +1206,9 @@
Programmatic flow decisions - In some situations, more information than the exit status may be - required to decide which step to execute next. In this case, a + In some situations, more information than the + ExitStatus may be required to decide which step + to execute next. In this case, a JobExecutionDecider can be used to assist in the decision. @@ -1261,10 +1269,10 @@ The above Resource will load the file from - the file system, at the location specified. Note that absolute locations - have to start with a double slash ("//"). In most spring applications, - this solution is good enough because the names of these are known at - compile time. However, in batch scenarios, the file name may need to be + the file system location specified. Note that absolute locations have to + start with a double slash ("//"). In most spring applications, this + solution is good enough because the names of these are known at compile + time. However, in batch scenarios, the file name may need to be determined at runtime as a parameter to the job. This could be solved using '-D' parameters, i.e. a system property: @@ -1284,10 +1292,11 @@ filters and does placeholder replacement on system properties.) Often in a batch setting it is preferable to parameterize the file - name in the JobParameters of the - job, instead of through system properties, and access them that way. To - allow for this, Spring Batch allows for the late binding of various Job - and Step attributes: + name in the JobParameters of + the job, instead of through system properties, and access them that way. + To accomplish this, Spring Batch allows for the late binding of various + Job and Step attributes: <bean id="flatFileItemReader" scope="step" @@ -1305,7 +1314,7 @@ <bean id="flatFileItemReader" scope="step" class="org.springframework.batch.item.file.FlatFileItemReader"> - <property name="resource" value="#{jobExecutionContext[input.file.name]}" /> + <property name="resource" value="#{jobExecutionContext[input.file.name]}" /> </bean> @@ -1313,7 +1322,7 @@ <bean id="flatFileItemReader" scope="step" class="org.springframework.batch.item.file.FlatFileItemReader"> - <property name="resource" value="#{stepExecutionContext[input.file.name]}" /> + <property name="resource" value="#{stepExecutionContext[input.file.name]}" /> </bean> @@ -1333,7 +1342,7 @@ Using a scope of Step is required in - order to use late binding, since the bean cannot actually be + order to use late binding since the bean cannot actually be instantiated until the Step starts, which allows the attributes to be found. Because it is not part of the Spring container by default, it must be added explicitly: