diff --git a/docs/src/site/docbook/reference/domain.xml b/docs/src/site/docbook/reference/domain.xml index d0d61bc6e..a25056af3 100644 --- a/docs/src/site/docbook/reference/domain.xml +++ b/docs/src/site/docbook/reference/domain.xml @@ -87,7 +87,7 @@ - In Spring Batch, a Job is simply a continer for Steps. It combines + In Spring Batch, a Job is simply a container for Steps. It combines multiple steps that belong logically together in a flow and allows for configuration of properties global to all steps, such as restartability. The job configuration contains: @@ -110,7 +110,7 @@ interface is provided by Spring Batch in the form of the SimpleJob class which creates some standard functionality on top of Job, however the batch - namespace abstracts away the need to instaniate it directly. Instead, the + namespace abstracts away the need to instantiate it directly. Instead, the <job> tag can be used: @@ -151,7 +151,7 @@ likely be a business decision, it is left up to the ItemReader to decide. What using the same JobInstance will determine, however, is whether - or not the 'state' (i.e. the ExecutionContext, which is discussed below) + or not the 'state' (i.e. The ExecutionContext, which is discussed below) from previous executions will be used. Using a new JobInstance will mean 'start from the beginning' and using an existing instance will generally mean 'start from where you @@ -756,7 +756,7 @@ schedule.Date - 2008-01-01 + 2008-01-01 @@ -917,7 +917,7 @@ As noted in the comment, ecStep will not equal ecJob, they are two different ExecutionContexts. The one scoped to the Step will be saved at every commit point in the - Step, wheras the one scoped to the + Step, whereas the one scoped to the Job will be saved in between every Step execution. @@ -995,4 +995,4 @@ that it's not valid, returning null indicates that it should not be written out. - \ No newline at end of file + diff --git a/docs/src/site/docbook/reference/images/job-repository-advanced.png b/docs/src/site/docbook/reference/images/job-repository-advanced.png new file mode 100644 index 000000000..5f84bff96 Binary files /dev/null and b/docs/src/site/docbook/reference/images/job-repository-advanced.png differ diff --git a/docs/src/site/docbook/reference/images/job-repository.png b/docs/src/site/docbook/reference/images/job-repository.png new file mode 100644 index 000000000..9c604cc28 Binary files /dev/null and b/docs/src/site/docbook/reference/images/job-repository.png differ diff --git a/docs/src/site/docbook/reference/job.xml b/docs/src/site/docbook/reference/job.xml index c352b8107..cc871b7dd 100644 --- a/docs/src/site/docbook/reference/job.xml +++ b/docs/src/site/docbook/reference/job.xml @@ -48,7 +48,7 @@ The namespace defaults to referencing a repository with an id of 'jobRepository', which is a sensible default. However, this can be - overriden explicitely: + overridden explicitly: <job id="footballJob" job-repository="specialRepository"> @@ -64,12 +64,13 @@ One key concern when execution a batch job, is what happens when a failed job is restarted? A Job is considered to have been 'restarted' if - the same JobInstance has more than one JobExecution. Ideally, all jobs - should be able to start up where they left off, but there are scenarios - where this is not possible. It is entirely up to - the developer to ensure that a new instance is always created in this - scenario. However, Spring Batch does provide some help. If a - Job should never be restarted, but should always be run as part of a new + the same JobInstance has more than one + JobExecution. Ideally, all jobs should be able to start up where they + left off, but there are scenarios where this is not possible. It is entirely up to the developer to ensure that a new + instance is always created in this scenario. However, Spring + Batch does provide some help. If a Job should never be restarted, but + should always be run as part of a new JobInstance, then the restartable property may be set to 'false': @@ -196,7 +197,7 @@
Configuring a JobRepository - As described in Chatper 2, the JobRepository is used for basic CRUD + As described in Chapter 2, the JobRepository is used for basic CRUD operations of the various persisted domain objects within Spring Batch, such as JobExecution and StepExecution. It is required by many of the major framework features, such as the JobLauncher, @@ -236,7 +237,7 @@ to collide in this way. However, since a call to the create* method is quite short, it is unlikely that the SERIALIZED will cause problems, as long as the database - platform supports it. However, this can be overriden: + platform supports it. However, this can be overridden: <job-repository id="jobRepository" @@ -264,7 +265,7 @@ This fragment can be used as is, with almost no changes. Remember - also to include the appropiate namespace declarations and to make sure + also to include the appropriate namespace declarations and to make sure spring-tx and spring-aop (or the whole of spring) is on the classpath. @@ -274,11 +275,11 @@ Spring Batch provides DDL samples for the meta-data tables in the Core jar file for several common database platforms. Index declarations are not included in that DDL because there are too many - variations in how users may want to index dependeing on their precise + variations in how users may want to index depending on their precise platform, local conventions and also the business requirements of how the jobs will be operated. The table below provides some indication as to which columns are going to be used in a WHERE clause by the Dao - ipmlementations provided by Spring Batch, and how frequently they + implementations provided by Spring Batch, and how frequently they might be used, so that individual projects can make up their own minds about indexing. @@ -679,7 +680,7 @@ - The JobExplorer and JobOperatoer interfaces, which will be discussed + The JobExplorer and JobOperator interfaces, which will be discussed below, add additional functionality for querying and controlling the meta data. @@ -783,8 +784,8 @@ JobRepository, JobExplorer, and JobRegistry. For this reason, the provided - implementation of JobOperator, SimpleJobOperator, has many dependencies: - + implementation of JobOperator, SimpleJobOperator, has many + dependencies: <bean id="jobOperator" class="org.springframework.batch.core.launch.support.SimpleJobOperator"> @@ -850,7 +851,7 @@ In this example, the value with a key of 'run.id' is used to - descriminate between JobInstances. If the JobParameters passed in is + discriminate between JobInstances. If the JobParameters passed in is null, it can be assumed that the Job has never been run before and thus it's initial state can be returned. However, if not, the old value is obtained, incremented by one, and returned. An incrementer can be @@ -889,4 +890,4 @@ for the JobExecution before finishing.
- \ No newline at end of file + diff --git a/docs/src/site/docbook/reference/readersAndWriters.xml b/docs/src/site/docbook/reference/readersAndWriters.xml index c9bf6b77e..aace9cf7b 100644 --- a/docs/src/site/docbook/reference/readersAndWriters.xml +++ b/docs/src/site/docbook/reference/readersAndWriters.xml @@ -331,14 +331,14 @@ - The basic constract is that, given the current line, and the - line number its associated with, return a resulting domain object. - This is similiar to RowMapper in that each line - is associated with it's line number, just as each row in a resultset - is tied to the row number it belongs to. This allows for tying the - line number to the resulting domain object for identitiy comparison, - or for more informative logging. However, unlike - RowMapper, the + The basic contract is that, given the current line, and the line + number its associated with, return a resulting domain object. This is + similar to RowMapper in that each line is + associated with it's line number, just as each row in a + ResultSet is tied to the row number it belongs + to. This allows for tying the line number to the resulting domain + object for identity comparison, or for more informative logging. + However, unlike RowMapper, the LineMapper is given a raw line which, as discussed above, only gets you halfway there. What is needed is tokenization of the line into a FieldSet, which @@ -566,7 +566,7 @@ There is one additional functionality a LineTokenizer that is similar in function to a - JDBC ResultSet. The names of the fields can be + Jdbc ResultSet. The names of the fields can be injected into the LineTokenizer to increase the readability of the mapping function. First, the column names of all fields in the flat file are injected into the @@ -608,10 +608,10 @@ For many, having to write a specific FieldSetMapper is equally as cumbersome as writing a specific RowMapper for a - JdbcTemplate. Spring Batch makes this easier by providing a - FieldSetMapper that automatically maps fields - by matching a field name with a setter on the object using the - JavaBean specification. Again using the football example, the + JdbcTemplate. Spring Batch makes this easier by + providing a FieldSetMapper that automatically + maps fields by matching a field name with a setter on the object using + the JavaBean specification. Again using the football example, the FieldSetMapper configuration looks like the following: @@ -641,7 +641,7 @@ Fixed Length file formats So far only delimited files have been discussed in much detail, - however, they respresent only half of the file reading picture. Many + however, they represent only half of the file reading picture. Many organizations that use flat files use fixed length formats. An example fixed length file is below: @@ -689,8 +689,8 @@ This LineTokenizer will return the same - FieldSet as if a dlimiter had been used, - allowing the same approachs above to be used such as the + FieldSet as if a delimiter had been used, + allowing the same approach above to be used such as the BeanWrapperFieldSetMapper, in a way that is ignorant of how the actual line was parsed. @@ -907,7 +907,7 @@
PassThroughLineAggregator - The most basic implementation of the LineAggreagot interface + The most basic implementation of the LineAggregator interface is the PassThroughLineAggregator, which simply assumes that the object is already a string, or that it's string representation is acceptable for writing: @@ -1000,7 +1000,7 @@ - File writing has similiar, but inverse steps: + File writing has similar, but inverse steps: @@ -1145,9 +1145,9 @@ Fixed Width File Writing Example Delimited is not the only type of flat file format, many prefer - to use a set width for each column to deliniate between fields, which + to use a set width for each column to delineate between fields, which is usually referred to as 'fixed width'. Spring Batch supports this in - file writting via the FormatterLineAggregator. Using the same + file writing via the FormatterLineAggregator. Using the same CustomerCredit domain object described above, it can be configured as follows: @@ -1248,7 +1248,7 @@ above. Everything between '<trade>' and '</trade>' is considered one 'fragment'. Spring Batch uses Object/XML Mapping (OXM) to bind fragments to objects. However, Spring Batch is not tied to any - particular xml binding technology. Typical use is to delegate to Spring OXM, which provides uniform abstraction for the most popular OXM technologies. The dependency on Spring OXM is optional and you @@ -1446,7 +1446,7 @@ optionally sets the overwriteOutput=true, mentioned earlier in the chapter for specifying whether an existing file can be overwritten. It should be noted the marshaller used for the writer is the exact same as - the one used in the reading example from ealier in the chapter: + the one used in the reading example from earlier in the chapter: <bean id="customerCreditMarshaller" class="org.springframework.oxm.xstream.XStreamMarshaller"> @@ -1592,7 +1592,7 @@
JdbcCursorItemReader - JdbcCursorItemReader is the JDBC + JdbcCursorItemReader is the Jdbc implementation of the cursor based technique. It works directly with a ResultSet and requires a SQL statement to run against a connection obtained from a @@ -1650,7 +1650,7 @@ DataSource, the provided SQL will be run against it, and the mapRow method will be called for each row in the ResultSet. Let's - constrast this with the approach of the + contrast this with the approach of the JdbcCursorItemReader: @@ -1717,7 +1717,7 @@ fetchSize - Gives the JDBC driver a hint as to the number of rows + Gives the Jdbc driver a hint as to the number of rows that should be fetched from the database when more rows are needed by the ResultSet object used by the ItemReader. By default, no hint is given. @@ -1768,10 +1768,10 @@ driverSupportsAbsolute - Defaults to false. Indicates whether the JDBC driver + Defaults to false. Indicates whether the Jdbc driver supports setting the absolute row on a ResultSet. It is recommended that - this is set to true for JDBC drivers that supports + this is set to true for Jdbc drivers that supports ResultSet.absolute() as it may improve performance, especially if a step fails while working with a large data set. @@ -1795,8 +1795,8 @@ 'READ_ONLY' and 'HOLD_CUSORS_OVER_COMMIT' options. This allows holding the cursor open over transaction start and commits performed in the step processing. To use this - feature you need a database that supports this and a JDBC - driver supporting JDBC 3.0 or later. + feature you need a database that supports this and a Jdbc + driver supporting Jdbc 3.0 or later. @@ -1888,7 +1888,7 @@ JdbcPagingItemReader needs a PagingQueryProvider responsible for providing the SQL queries used to retrieve the rows making up a page. Since each - database has its own strategy for proviing paging support, we need to + database has its own strategy for providing paging support, we need to use a different PagingQueryProvider for each supported database type. There is also the SimpleDelegatingPagingQueryProvider that will @@ -1952,7 +1952,7 @@ ItemReader is the JpaPagingItemReader. JPA doesn't have a concept similar to the Hibernate StatelessSession so we - have to use other features provided by the JPA specification. SInce + have to use other features provided by the JPA specification. Since JPA supports paging, this is a natural choice when it comes to using JPA for batch processing. After each page is read the entities will become detached and the persistence context will be cleared in order @@ -2021,7 +2021,7 @@ IbatisPagingItemReader and there is also a _page variable that can be used if necessary. The syntax for the paging queries varies with the database used. Here - is an example for Oracle (unfortunatey we need to use CDATA for some + is an example for Oracle (unfortunately we need to use CDATA for some operators since this belongs in an XML document): <select id="getPagedCustomerCredits" resultMap="customerCreditResult"> @@ -2044,9 +2044,9 @@ for files because they must act as if they're transactional, keeping track of written items and flushing or clearing at the appropriate times. Databases have no need for this functionality, since the write is - already contained in a transaction. Users can create their own DAO's - that implement the ItemWriter interface or use - one from a custom ItemWriter that's written for + already contained in a transaction. Users can create their own DAOs that + implement the ItemWriter interface or use one + from a custom ItemWriter that's written for generic processing concerns, either way, they should work without any issues. One thing to look out for is the performance and error handling capabilities that are provided by batching the outputs. This is most @@ -2201,10 +2201,10 @@ } An ItemProcessor is very simple, given one - object, transorm it and return another. The object provided may or may not - be of the same type. The point is that business logic may be applied + object, transform it and return another. The object provided may or may + not be of the same type. The point is that business logic may be applied within process, and is completely up to the developer to create. An - ItemProcessor can be wired direclty into a step, + ItemProcessor can be wired directly into a step, For example, assuming an ItemReader provides a class of type Foo, and it needs to be converted to type Bar before being written out. An ItemTransformer can be written that @@ -2346,7 +2346,7 @@ itemProcessors.add(new BarTransformer()); compositeProcessor.setItemProcessors(itemProcessors); - Just as with the previous example, the compsite processor can be + Just as with the previous example, the composite processor can be configured into the Step: @@ -2453,7 +2453,7 @@ flipped from false to true. The SQL statement can then contain an extra statement in the where clause, such as: "where PROCESSED_IND = false", thereby insuring that only unprocessed records will be returned in the - case of a restart. In this scenario, it is prefereable to not store any + case of a restart. In this scenario, it is preferable to not store any state, such as the current row number, since it will be irrelevant upon restart. For this reason, all readers and writers include the 'saveState' property: @@ -2557,9 +2557,9 @@ actually valid in many scenarios, but it is sometimes preferable that a batch job starts off at where it left off. The key discriminant is often whether the reader is stateful or stateless. A stateless reader - does not need to worry about restartablility, but a stateful one has - to try and reconstitute its last known state on restart. For this - reason, we recommend that you keep custom readers stateless as far as + does not need to worry about restartability, but a stateful one has to + try and reconstitute its last known state on restart. For this reason, + we recommend that you keep custom readers stateless as far as possible, so you don't have to worry about restartability. If you do need to store state, then in Spring Batch, this is @@ -2696,4 +2696,4 @@
- \ No newline at end of file + diff --git a/docs/src/site/docbook/reference/repeat.xml b/docs/src/site/docbook/reference/repeat.xml index 1a15c52da..ff53841d7 100644 --- a/docs/src/site/docbook/reference/repeat.xml +++ b/docs/src/site/docbook/reference/repeat.xml @@ -8,7 +8,7 @@ RepeatTemplate Batch processing is about repetitive actions - either as a simple - optimisation, or as part of a job. To strategise and generalise the + 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: @@ -137,10 +137,10 @@ template.iterate(new RepeatCallback() { 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 teh continuable + values, as long as the semantics of the continuable property are honoured. - ExitStatus values can also be combined with valrious operators + 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 @@ -163,7 +163,7 @@ template.iterate(new RepeatCallback() { the loop in the iterate method is determined by a CompletionPolicy which is also a factory for the ReapeatContext. The - RepeatTemplate has the reponsibility to use the + RepeatTemplate has the responsibility to use the current policy to create a RepeatContext and pass that in to the RepeatCallback at every stage in the iteration. After a callback completes its @@ -319,4 +319,4 @@ template.iterate(new RepeatCallback() { ExceptionHandler in the provided RepeatTemplate. - \ No newline at end of file + diff --git a/docs/src/site/docbook/reference/retry.xml b/docs/src/site/docbook/reference/retry.xml index 09262c2c9..46be89dd4 100644 --- a/docs/src/site/docbook/reference/retry.xml +++ b/docs/src/site/docbook/reference/retry.xml @@ -17,27 +17,27 @@ RetryOperations strategy. The RetryOperations interface looks like this: - public interface RetryOperations { - T execute(RetryCallback retryCallback) throws Exception; + <T> T execute(RetryCallback<T> retryCallback) throws Exception; - T execute(RetryCallback retryCallback, RecoveryCallback recoveryCallback) + <T> T execute(RetryCallback<T> retryCallback, RecoveryCallback<T> recoveryCallback) throws Exception; - T execute(RetryCallback retryCallback, RetryState retryState) + <T> T execute(RetryCallback<T> retryCallback, RetryState retryState) throws Exception, ExhaustedRetryException; - T execute(RetryCallback retryCallback, RecoveryCallback recoveryCallback, + <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 +}where the basic callback is a simple interface that allows + you to insert some business logic to be retried - { + public interface RetryCallback<T> { T doWithRetry(RetryContext context) throws Throwable; -}]]>The callback is executed and if it fails (by throwing an +}The callback is executed and if it fails (by throwing an Exception), it will be retried until either it is successful, or the implementation decides to abort. There are a number of overloaded execute methods in the @@ -50,18 +50,18 @@ RetryOperations is RetryTemplate. It could be used like this - RetryTemplate template = new RetryTemplate(); template.setRetryPolicy(new TimeoutRetryPolicy(30000L)); -Foo result = template.execute(new RetryCallback() { +Foo result = template.execute(new RetryCallback<Foo>() { public Foo doWithRetry(RetryContext context) { // Do stuff that might fail, e.g. webservice operation return result; } -});]]> +}); In the example we execute a web service call and return the result to the user. If that call fails then it is retried until a timeout is @@ -90,17 +90,17 @@ Foo result = template.execute(new RetryCallback() { 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) { // business logic here }, - new RecoveryCallback() { + new RecoveryCallback<Foo>() { Foo recover(RetryContext context) throws Exception { // recover logic here } -});]]>If the business logic does not succeed before the - template decides to abort, then the client is given the chance to do - some alternate processing through the recovery callback. +});If the business logic does not succeed before the template + decides to abort, then the client is given the chance to do some + alternate processing through the recovery callback.
@@ -144,7 +144,7 @@ Foo result = template.execute(new RetryCallback() { RetryContextCache with a cluster cache of some sort (even in a clustered environment this might be overkill). - Part of the reponsibility of the + Part of the responsibility of the RetryOperations is to recognise 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 @@ -189,7 +189,7 @@ Foo result = template.execute(new RetryCallback() { or fail in the execute method is determined by a RetryPolicy which is also a factory for the RetryContext. The - RetryTemplate has the reponsibility to use the + RetryTemplate has the responsibility to use the current policy to create a RetryContext and pass that in to the RetryCallback at every attempt. After a callback fails the RetryTemplate has to @@ -210,8 +210,9 @@ Foo result = template.execute(new RetryCallback() { 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 determinstic 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 could be a + very tight loop retrying something that you know in advance is + fatal. Spring Batch provides some simple general purpose implementations of @@ -226,7 +227,7 @@ Foo result = template.execute(new RetryCallback() { this list overrides the retryable list, so it can be used to give finer control over the retry behaviour, e.g. - SimpleRetryPolicy policy = new SimpleRetryPolicy(5); // Retry on all exceptions (this is the default) policy.setRetryableExceptions(new Class[] {Exception.class}); // ... but never retry IllegalStateException @@ -235,11 +236,11 @@ policy.setFatalExceptions(new Class[] {ILlegalStateException.class}); // Use the policy... RetryTemplate template = new RetryTemplate(); template.setRetryPolicy(policy); -template.execute(new RetryCallback() { +template.execute(new RetryCallback<Foo>() { public Foo doWithRetry(RetryContext context) { // business logic here } -});]]> +}); There is also a more flexible implementation called ExceptionClassifierRetryPolicy, which allows the @@ -265,20 +266,20 @@ template.execute(new RetryCallback() { RetryTemplate can pause execution according to the BackoffPolicy in place. - public interface BackoffPolicy { BackOffContext start(RetryContext context); void backOff(BackOffContext backOffContext) throws BackOffInterruptedException; -}]]>A BackoffPolicy is free to - implement the backOff in any way it chooses. The policies provided by - Spring Batch out of the box all use Object.wait(). A common - use case is to backoff with an exponentially increasing wait period, to - avoid two retries getting into lock step and both failing - this is a - lesson learned from the ethernet. For this purpose Spring Batch provides - the ExponentialBackoffPolicy. +}A BackoffPolicy is free to implement + the backOff in any way it chooses. The policies provided by Spring Batch + out of the box all use Object.wait(). A common use case is to + backoff with an exponentially increasing wait period, to avoid two retries + getting into lock step and both failing - this is a lesson learned from + the ethernet. For this purpose Spring Batch provides the + ExponentialBackoffPolicy.
@@ -295,15 +296,15 @@ template.execute(new RetryCallback() { The interface looks like this: - public interface RetryListener { - void open(RetryContext context, RetryCallback callback); + void open(RetryContext context, RetryCallback<T> callback); - void onError(RetryContext context, RetryCallback callback, Throwable e); + void onError(RetryContext context, RetryCallback<T> callback, Throwable e); - void close(RetryContext context, RetryCallback callback, Throwable e); + void close(RetryContext context, RetryCallback<T> callback, Throwable e); } -]]>The open and +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 @@ -334,20 +335,20 @@ template.execute(new RetryCallback() { remoteCall (for more detail on how to configure AOP interceptors see the Spring User Guide): - - - - + <aop:config> + <aop:pointcut id="transactional" + expression="execution(* com...*Service.remoteCall(..))" /> + <aop:advisor pointcut-ref="transactional" + advice-ref="retryAdvice" order="-1"/> +</aop:config> - -]]> +<bean id="retryAdvice" + class="org.springframework.batch.retry.interceptor.RetryOperationsInterceptor"/> + The example above uses a default RetryTemplate inside the interceptor. To change the - policies, listeners etc. you only need to inject an instance of + policies or listeners, you only need to inject an instance of RetryTemplate into the interceptor.
- \ No newline at end of file + diff --git a/docs/src/site/docbook/reference/schema-appendix.xml b/docs/src/site/docbook/reference/schema-appendix.xml index c7c1b28da..250bfaf5e 100644 --- a/docs/src/site/docbook/reference/schema-appendix.xml +++ b/docs/src/site/docbook/reference/schema-appendix.xml @@ -510,7 +510,7 @@ INSERT INTO BATCH_JOB_SEQ values(0);
Archiving - Because there are entries in multiple tables everytime a batch job + Because there are entries in multiple tables every time a batch job is run, it is common to create an archive strategy for the meta-data tables. The tables themselves are designed to show a record of what happened in the past, and generally won't affect the run of any job, with @@ -538,4 +538,4 @@ INSERT INTO BATCH_JOB_SEQ values(0);
- \ No newline at end of file + diff --git a/docs/src/site/docbook/reference/step.xml b/docs/src/site/docbook/reference/step.xml index a792dbc4c..c361287f8 100644 --- a/docs/src/site/docbook/reference/step.xml +++ b/docs/src/site/docbook/reference/step.xml @@ -1257,12 +1257,12 @@ The above Resource will load the file from - the file system, at the location specificied. 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 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: <bean id="flatFileItemReader" @@ -1332,7 +1332,7 @@ 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: + Spring container by default, it must be added explicitly: <bean class="org.springframework.batch.core.scope.StepScope" /> @@ -1341,4 +1341,4 @@ - \ No newline at end of file + diff --git a/docs/src/site/docbook/reference/testing.xml b/docs/src/site/docbook/reference/testing.xml index 9fcab4f1e..1312e35d7 100644 --- a/docs/src/site/docbook/reference/testing.xml +++ b/docs/src/site/docbook/reference/testing.xml @@ -10,7 +10,7 @@ detail, so it won't be repeated here. It is important, however, to think about how to 'end to end' test a batch job, which is what this chapter will focus on. The spring-batch-test project includes classes that will help - factillitate this end-to-end test approach. + facilitate this end-to-end test approach.
Creating a Unit Test Class @@ -27,7 +27,7 @@ @ContextConfiguration(locations = {...}): - Indicates which xml files contain the ApplicationContext. + Indicates which XML files contain the ApplicationContext. @@ -93,9 +93,9 @@
Testing Individual Steps - For complex batch jobs, test cases in the end-to-end tesing approach - may become unmanageable. It these cases, it may be more useful to have - test cases to test individual steps on their own. The + For complex batch jobs, test cases in the end-to-end testing + approach may become unmanageable. It these cases, it may be more useful to + have test cases to test individual steps on their own. The AbstractJobTests class contains a method launchStep that takes a step name and runs just that particular Step. This approach allows for more