From aff922709d1f74ca495e858d05653d25e00e72ba Mon Sep 17 00:00:00 2001 From: dhgarrette Date: Wed, 11 Feb 2009 21:18:48 +0000 Subject: [PATCH] Reapplied changes overwritten by rev 2959 --- docs/src/site/docbook/reference/step.xml | 590 ++++++++++++++--------- 1 file changed, 367 insertions(+), 223 deletions(-) diff --git a/docs/src/site/docbook/reference/step.xml b/docs/src/site/docbook/reference/step.xml index 10fd3001e..4d9eeb42d 100644 --- a/docs/src/site/docbook/reference/step.xml +++ b/docs/src/site/docbook/reference/step.xml @@ -4,7 +4,7 @@ Configuring a Step - As disucssed in , a + As discussed in , a Step is a domain object that encapsulates an independent, sequential phase of a batch job and contains all of the information necessary to define and control the actual batch processing. @@ -31,7 +31,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 @@ -43,14 +43,13 @@ + fileref="images/chunk-oriented-processing.png" width="75%" /> @@ -60,7 +59,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); @@ -119,8 +119,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.
@@ -129,7 +130,7 @@ While steps must exist within a Job to define the flow, it can sometimes be useful to reference a 'standalone' Step. For example, if a Step is used by multiple jobs it can be useful to declare it once and - reference it from multiple jobs. This can be achieved with the ref + reference it from multiple jobs. This can be achieved with the 'ref' attribute: @@ -149,7 +150,7 @@ The Id will be used as the step name when persisting the - StepExecution, if the same standalone step is referenced in more + StepExecution. If the same standalone step is referenced in more than one step in the job, an error will occur. @@ -167,13 +168,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"> @@ -205,14 +207,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 id="step1"> @@ -360,7 +363,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. @@ -398,15 +401,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 id="step1"> @@ -435,8 +438,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 @@ -475,7 +478,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 id="step1"> @@ -487,8 +491,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.
@@ -501,8 +505,8 @@ top of a transactional resource, such as a JMS queue. In this case, since the queue is tied to the transaction that is rolled back, the messages that have been pulled from the queue will be put back on. For - this reason, the step can be configured to not buffer the items: - + this reason, the step can be configured to not buffer the + items: <step id="step1"> @@ -520,21 +524,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 id="step1"> @@ -563,11 +567,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.
@@ -597,7 +601,7 @@ In addition to the StepListener interfaces, - annotations are provided address the same concerns. + annotations are provided to address the same concerns.
StepExecutionListener @@ -800,9 +804,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 @@ -813,9 +818,9 @@ void onSkipInRead(Throwable t); - void onSkipInWrite(S item, Throwable t); - void onSkipInProcess(T item, Throwable t); + + void onSkipInWrite(S item, Throwable t); } @@ -851,8 +856,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: @@ -900,8 +905,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 @@ -933,7 +938,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 @@ -976,7 +981,7 @@ <job id="taskletJob"> - <step name="deleteFilesInDir" tasklet="fileDeletingTasklet"/> + <step id="deleteFilesInDir" tasklet="fileDeletingTasklet"/> </job> <bean id="fileDeletingTasklet" @@ -989,27 +994,6 @@ </property> </bean> - -
- -
- Executing System Commands - - Many batch jobs may require that an external command be called - from within the batch job. Such a process could be kicked off separately - by the scheduler, but the advantage of common meta-data about the run - would be lost. Furthermore, a multi-step job would also need to be split - up into multiple jobs as well. Because the need is so common, Spring - Batch provides a Tasklet implementation for - calling system commands: - - - <bean class="org.springframework.batch.sample.tasklet.SystemCommandTasklet"> - <property name="command" value="echo hello" /> - <!-- 5 second timeout for the command to complete --> - <property name="timeout" value="5000" /> - </bean> -
@@ -1017,11 +1001,11 @@
Controlling Step Flow - With the ability to group steps together within an owning job, comes + 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. @@ -1035,17 +1019,17 @@ + scale="80" width="40%" /> + width="40%" /> - This can be achieved using the 'next' attribute of - Step: + This can be achieved using the 'next' attribute of the step + element: <job id="job"> @@ -1054,31 +1038,42 @@ <step id="stepC" /> </job> -In the scenario above, 'step A' will execute first. If 'step - A' completes normally, then 'step B' will execute and so on. However, if - 'step A' fails, then the entire Job will fail and - 'step B' will not execute. +In the scenario above, 'step A' will execute first because it + is the first Step listed. If 'step A' completes + normally, then 'step B' will execute, and so on. However, if 'step A' + fails, then the entire Job will fail and 'step B' + will not execute. + + + With the Spring Batch namespace, the first step listed in the + configuration will always be the first step + executed by the Job. The order of the other + step elements does not matter, but the first step must always appear + first in the xml. +
Conditional Flow - In the example above, there's only two possibilities: + In the example above, there are only two possibilities: - The Step is successful and the next Step should be - executed + The Step is successful and the next + Step should be executed. - The Step failed and thus the Job should fail. + The Step failed and thus the + Job should fail. - In many cases this may be sufficient. However, what about a - scenario in which the failure of a Step should trigger a different Step, - rather than causing failure? + In many cases, this may be sufficient. However, what about a + scenario in which the failure of a Step should + trigger a different Step, rather than causing + failure? @@ -1086,15 +1081,41 @@ + width="40%" /> - In order to handle this scenario, the next step can be determined - based on the result of the step by adding a next element to the Step. - The "on" attribute uses a simple pattern-matching scheme to match the - exit code of the Step to the various next elements declared. Only two - special characters are allowed: + In order to handle more complex scenarios, the + Spring Batch namespace allows transition elements to be defined within + the step element. One such transition is the "next" element. Like the + "next" attribute, the "next" element will tell the + Job which Step to execute + next. However, unlike the attribute, any number of "next" elements are + allowed on a given Step, and there is no default + behavior the the case of failure. This means that if transition elements + are used, then all of the behavior for the Step's + transitions must be defined explicitly. Note also that a single step + cannot have both a "next" attribute and a transtion element. + + The next element specifies a pattern to match and the step to + execute next: + + + <job id="job"> + <step id="stepA"> + <next on="FAILED" to="stepB" /> + <next on="*" to="stepC" /> + </step> + <step id="stepB" next="stepC" /> + <step id="stepC" /> + </job> + + + + The "on" attribute of a transition element uses a simple + pattern-matching scheme to match the ExitStatus + that results from the exeution of the Step. Only + two special characters are allowed in the pattern: @@ -1109,27 +1130,17 @@ For example, "c*t" will match "cat" and "count", while "c?t" will match "cat" but not "count". - Any number of "next" elements is allowed, but if the step has an - exit code that is not covered by a "next" element, then the framework - will throw an exception and the job will fail. It is important to note - that the framework will automatically order transitions from most - specific to least specific. So even if the "next" elements were swapped - for "stepA" below, an exit status of "FAILED" would still go to - "stepB". + While there is no limit to the number of transition elements on a + Step, if the Step's + execution results in an ExitStatus that is not + covered by an element, then the framework will throw an exception and + the Job will fail. It is important to note that + the framework will automatically order transitions from most specific to + least specific. This means that even if the elements were swapped for + "stepA" in the example above, an ExitStatus of + "FAILED" would still go to "stepB". - - <job id="job"> - <step id="stepA"> - <next on="FAILED" to="stepB" /> - <next on="*" to="stepC" /> - </step> - <step id="stepB" next="stepC" /> - <step id="stepC" /> - </job> - - - -
+
Batch Status vs. Exit Status When configuring a Job for conditional @@ -1138,11 +1149,11 @@ 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. - Most of them are self explanatory, COMPLETED is the status set when a + Most of them are self explanatory: COMPLETED is the status set when a step or job has completed successfully, FAILED is set when it fails, and so on. The example above contains the following 'next' element: @@ -1154,18 +1165,18 @@ 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 - ExitCode of the + Step to which it belongs. However, it actually + 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 exit code 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 id="step1"> @@ -1180,83 +1191,189 @@ - The step failed, in which case the job should fail. + The Step failed, in which case the + job should fail. - The Step completed successfully. + The Step completed + successfully. - The Step completed successfully, but with an exit code of - 'COMPLETED WITH SKIPS'. In this case, a different step should be - run to handle the errors. + The Step completed successfully, but + with an exit code of 'COMPLETED WITH SKIPS'. In this case, a + different step should be run to handle the errors. - 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: - public class SkipCheckingListener implements StepExecutionListener { + public class SkipCheckingListener extends StepExecutionListenerSupport { - public ExitStatus afterStep(StepExecution stepExecution) { - if (!stepExecution.getExitStatus().getExitCode().equals(ExitStatus.FAILED.getExitCode()) - && stepExecution.getSkipCount() > 0) { - return new ExitStatus("COMPLETED WITH SKIPS"); - } else { - return null; + public ExitStatus afterStep(StepExecution stepExecution) { + if (!stepExecution.getExitStatus().getExitCode().equals(ExitStatus.FAILED.getExitCode()) + && stepExecution.getSkipCount() > 0) { + return new ExitStatus("COMPLETED WITH SKIPS"); + } else { + return null; + } } - } - ... -} + } The above code is a StepExecutionListener 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.
Configuring for Stop - If it is desired that the batch job stop under certain conditions, - then either the "stop" tag or the "end" tag may be used. + After the discussion of BatchStatus and + ExitStatus, one might wonder how the + BatchStatus and ExitStatus + are determined for the Job. While these statuses + are determined for the Step by the code that is + executed, the statuses for the Job will be + determined based on the configuration. - The "stop" tag indicates the job should stop processing with an - exit status of "STOPPED". The "to" attribute tells the framework which - step should be first when the job is subsequently restarted. This - mechanism allows the job to pause temporarily. + So far, all of the job configurations discussed have had at least + one final Step with no transitions. For example, + after the following step executes, the Job will + end: - On the other hand, the "end" tag will stop the job but does not - allow for a "to" attribute. The "status" attribute is optional. It will - determine the exit status of the step if the flow ends at that location. - The only legal values for the "status" are "COMPLETED", "FAILED", and - "STOPPED". If no status is specified, then the default is - "COMPLETED". + <step id="stepC" /> - - <step id="step1"> - <stop on="COMPLETED" to="step2"/> - </step> + If no transitions are defined for a Step, + then the Job's statuses will be defined as + follows: + + + + If the Step ends with + ExitStatus FAILED, then the + Job's BatchStatus and + ExitStatus will both be FAILED. + + + + Otherwise, the the Job's + BatchStatus and + ExitStatus will both be COMPLETED. + + + + While this method of terminating a batch job is sufficient for + some batch jobs, such as a simple sequential step job, custom defined + job-stopping scenarios may be required. For this purpose, Spring Batch + provides three transition elements to stop a Job + (in addition to the "next" element + that we discussed previously). Each of these stopping elements will stop + a Job with a particular + BatchStatus. It is important to note that the + stop transition elements will have no effect on either the + BatchStatus or ExitStatus + of any Steps in the Job: + these elements will only affect the final statuses of the + Job. For example, it is possible for every step + in a job to have a status of FAILED but the job to have a status of + COMPLETED, or vise versa. + +
+ The 'End' Element + + The 'end' element instructs a Job to stop + with a BatchStatus of COMPLETED. A + Job that has finished with status COMPLETED + cannot be restarted (the framework will throw a + JobInstanceAlreadyCompleteException). The 'end' + element also allows for an optional 'status' attribute that can be + used to customize the ExitStatus of the + Job. If no 'status' attribute is given, then + the ExitStatus will be "COMPLETED" by default, + to match the BatchStatus. + + In the following scenario, if step2 fails, then the + Job will stop with a + BatchStatus of COMPLETE and an + ExitStatus of "COMPLETED" and step3 will not + execute; otherwise, execution will move to step3. Additionally, if + step2 fails, the Job will not be + restartable. + + <step id="step1" next="step2"> <step id="step2"> - <next on="FOO" to="step3"/> - <end on="*" status="FAILED"/> + <end on="FAILED"/> + <next on="*" to="step3"/> </step> - <step id="step3" /> + <step id="step3"> +
- +
+ The 'Fail' Element + + The 'fail' element instructs a Job to + stop with a BatchStatus of FAILED. Unlike the + 'end' element, the 'fail' element will not prevent the + Job from being restarted. The 'fail' element + also allows for an optional 'status' attribute that can be used to + customize the ExitStatus of the + Job. If no 'status' attribute is given, then + the ExitStatus will be "FAILED" by default, to + match the BatchStatus. + + In the following scenario, if step2 fails, then the + Job will stop with a + BatchStatus of FAILED and an + ExitStatus of "EARLY TERMINATION" and step3 + will not execute; otherwise, execution will move to step3. + Additionally, if step2 fails, and the Job is + restarted, then execution will begin again on step2. + + <step id="step1" next="step2"> + <step id="step2"> + <fail on="FAILED" status="EARLY TERMINATION"/> + <next on="*" to="step3"/> + </step> + <step id="step3"> +
+ +
+ The 'Pause' Element + + The 'pause' element instructs a Job to + stop with a BatchStatus of STOPPED. Pausing a + Job is a meant to be a temporary break in + processing so that the operator can take some action before restarting + the Job. The 'pause' element requires a 'to' + attribute that specifies the step where execution should pick up once + the Job. + + In the following scenario, if step1 finsihes with COMPLETE, then + the job will then stop. Once it is restarted, execution will begin on + step2. + + <step id="step1"> + <pause on="COMPLETED" to="step2"/> + </step> + <step id="step2"/> +
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. @@ -1298,16 +1415,43 @@
- Late binding of Job and Step Attributes + Split Flows - Both the XML and Flat File examples above use the Spring - Resource abstraction to obtain a file . This - works because Resource has a - getFile method, which returns a - java.io.File. Both XML and Flat File resources - can be configured using standard Spring constructs: + Every scenario described so far has involved a + Job that executes its + Steps one at a time in a linear fashion. In + addition to this typical style, the Spring Batch namespace also allows + for a job to be configured with parallel flows using the 'split' + element. As is seen below, the 'split' element contains one or more + 'flow' elements, where entire separate flows can be defined. A 'split' + element may also contain any of the previously discussed transition + elements such as the 'next' attribute or the 'next', 'end', 'fail', or + 'pause' elements. - + <split id="split1" next="step4"> + <flow> + <step id="step1" next="step2"/> + <step id="step2"/> + </flow> + <flow> + <step id="step3"/> + </flow> + </split> + <step id="step4"/> +
+
+ +
+ Late binding of Job and Step Attributes + + Both the XML and Flat File examples above use the Spring + Resource abstraction to obtain a file . This works + because Resource has a getFile + method, which returns a java.io.File. Both XML and + Flat File resources can be configured using standard Spring + constructs: + + <bean id="flatFileItemReader" class="org.springframework.batch.item.file.FlatFileItemReader"> <property name="resource" @@ -1316,15 +1460,15 @@ - 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 - determined at runtime as a parameter to the job. This could be solved - using '-D' parameters, i.e. a system property: + The above Resource will load the file from + 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: - + <bean id="flatFileItemReader" class="org.springframework.batch.item.file.FlatFileItemReader"> <property name="resource" value="${input.file.name}" /> @@ -1332,20 +1476,21 @@ - All that would be required for this solution to work would be a - system argument (-Dinput.file.name="file://file.txt"). (Note that - although a PropertyPlaceholderConfigurer can be - used here, it is not necessary if the system property is always set - because the ResourceEditor in Spring already - filters and does placeholder replacement on system properties.) + All that would be required for this solution to work would be a + system argument (-Dinput.file.name="file://file.txt"). (Note that although + a PropertyPlaceholderConfigurer can be used here, + it is not necessary if the system property is always set because the + ResourceEditor in Spring already 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: + 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 + accomplish this, Spring Batch allows for the late binding of various Job + and Step attributes: - + <bean id="flatFileItemReader" scope="step" class="org.springframework.batch.item.file.FlatFileItemReader"> <property name="resource" value="#{jobParameters[input.file.name]}" /> @@ -1353,34 +1498,34 @@ - Both the JobExecution and - StepExecution level - ExecutionContext can be accessed in the same - way: + Both the JobExecution and + StepExecution level + ExecutionContext can be accessed in the same + way: - + <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> - + <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> -
- Step Scope +
+ Step Scope - All of the late binding examples from above have a scope of - "step" declared on the bean definition: + All of the late binding examples from above have a scope of "step" + declared on the bean definition: - + <bean id="flatFileItemReader" scope="step" class="org.springframework.batch.item.file.FlatFileItemReader"> <property name="resource" value="#{jobParameters[input.file.name]}" /> @@ -1388,17 +1533,16 @@ - Using a scope of Step is required in - 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: + Using a scope of Step is required in 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: - + <bean class="org.springframework.batch.core.scope.StepScope" /> -