From 09646d893880cf98270bfd91ea9acd9537566589 Mon Sep 17 00:00:00 2001 From: Mahmoud Ben Hassine Date: Fri, 29 May 2020 21:19:54 +0200 Subject: [PATCH] Update docs Fix incorrect git meta-data (<<<<<<< HEAD) introduced mistakenly in efdce56 which was causing asciidoc warnings --- spring-batch-docs/asciidoc/jsr-352.adoc | 443 ++++++++++++------------ 1 file changed, 217 insertions(+), 226 deletions(-) diff --git a/spring-batch-docs/asciidoc/jsr-352.adoc b/spring-batch-docs/asciidoc/jsr-352.adoc index df2fd1459..56c5f86cc 100644 --- a/spring-batch-docs/asciidoc/jsr-352.adoc +++ b/spring-batch-docs/asciidoc/jsr-352.adoc @@ -10,60 +10,66 @@ ifndef::onlyonetoggle[] include::toggle.adoc[] endif::onlyonetoggle[] -As of Spring Batch 3.0 support for JSR-352 has been fully implemented. This section is not -a replacement for the spec itself and instead, intends to explain how the JSR-352 specific -concepts apply to Spring Batch. Additional information on JSR-352 can be found via the -JCP here: -link:$$https://jcp.org/en/jsr/detail?id=352$$[https://jcp.org/en/jsr/detail?id=352] +As of Spring Batch 3.0 support for JSR-352 has been fully implemented. This section is not a replacement for +the spec itself and instead, intends to explain how the JSR-352 specific concepts apply to Spring Batch. +Additional information on JSR-352 can be found via the +JCP here: link:$$https://jcp.org/en/jsr/detail?id=352$$[https://jcp.org/en/jsr/detail?id=352] [[jsrGeneralNotes]] === General Notes about Spring Batch and JSR-352 -Spring Batch and JSR-352 are structurally the same. They both have jobs that are made up -of steps. They both have readers, processors, writers, and listeners. However, their -interactions are subtly different. For example, the -`org.springframework.batch.core.SkipListener#onSkipInWrite(S item, Throwable t)` within -Spring Batch receives two parameters: the item that was skipped and the Exception that -caused the skip. The JSR-352 version of the same method +Spring Batch and JSR-352 are structurally the same. They both have jobs that are made up of steps. They +both have readers, processors, writers, and listeners. However, their interactions are subtly different. +For example, the `org.springframework.batch.core.SkipListener#onSkipInWrite(S item, Throwable t)` +within Spring Batch receives two parameters: the item that was skipped and the Exception that caused the +skip. The JSR-352 version of the same method (`javax.batch.api.chunk.listener.SkipWriteListener#onSkipWriteItem(List<Object> items, Exception ex)`) -also receives two parameters. However the first one is a `List` of all the items within -the current chunk with the second being the `Exception` that caused the skip. Because of -these differences, it is important to note that there are two paths to execute a job -within Spring Batch: either a traditional Spring Batch job or a JSR-352 based job. While -the use of Spring Batch artifacts (readers, writers, etc) will work within a job -configured with JSR-352's JSL and executed with the `JsrJobOperator`, they behave -according to the rules of JSR-352. It is also important to note that batch artifacts that -have been developed against the JSR-352 interfaces will not work within a traditional -Spring Batch job. +also receives two parameters. However the first one is a `List` of all the items +within the current chunk with the second being the `Exception` that caused the skip. +Because of these differences, it is important to note that there are two paths to execute a job within +Spring Batch: either a traditional Spring Batch job or a JSR-352 based job. While the use of Spring Batch +artifacts (readers, writers, etc) will work within a job configured with JSR-352's JSL and executed with the +`JsrJobOperator`, they will behave according to the rules of JSR-352. It is also +important to note that batch artifacts that have been developed against the JSR-352 interfaces will not work +within a traditional Spring Batch job. [[jsrSetup]] + + === Setup [[jsrSetupContexts]] + + ==== Application Contexts -All JSR-352 based jobs within Spring Batch consist of two application contexts. A parent -context, that contains beans related to the infrastructure of Spring Batch such as the -`JobRepository`, `PlatformTransactionManager`, etc and a child context that consists of -the configuration of the job to be run. The parent context is defined via the -`baseContext.xml` provided by the framework. This context may be overridden by setting -the `JSR-352-BASE-CONTEXT` system property. +All JSR-352 based jobs within Spring Batch consist of two application contexts. A parent context, that +contains beans related to the infrastructure of Spring Batch such as the `JobRepository`, +`PlatformTransactionManager`, etc and a child context that consists of the configuration +of the job to be run. The parent context is defined via the `jsrBaseContext.xml` provided +by the framework. This context may be overridden by setting the `JSR-352-BASE-CONTEXT` system +property. + [NOTE] ==== -The base context is not processed by the JSR-352 processors for things like property -injection so that no components requiring that additional processing should be configured -there. +The base context is not processed by the JSR-352 processors for things like property injection so +no components requiring that additional processing should be configured there. + ==== [[jsrSetupLaunching]] + + ==== Launching a JSR-352 based job -JSR-352 requires a very simple path to executing a batch job. The following code is all -that is needed to execute your first batch job: +JSR-352 requires a very simple path to executing a batch job. The following code is all that is needed to +execute your first batch job: + + [source, java] ---- @@ -71,91 +77,101 @@ JobOperator operator = BatchRuntime.getJobOperator(); jobOperator.start("myJob", new Properties()); ---- -While that is convenient for developers, the devil is in the details. Spring Batch -bootstraps a bit of infrastructure behind the scenes that a developer may want to -override. The following is bootstrapped the first time `BatchRuntime.getJobOperator()` -is called: +While that is convenient for developers, the devil is in the details. Spring Batch bootstraps a bit of +infrastructure behind the scenes that a developer may want to override. The following is bootstrapped the +first time `BatchRuntime.getJobOperator()` is called: |=============== |__Bean Name__|__Default Configuration__|__Notes__ | -dataSource -| -Apache DBCP BasicDataSource with configured values. -| -By default, HSQLDB is bootstrapped. + dataSource + | + Apache DBCP BasicDataSource with configured values. + | + By default, HSQLDB is bootstrapped. |`transactionManager`|`org.springframework.jdbc.datasource.DataSourceTransactionManager`| -References the dataSource bean defined above. + References the dataSource bean defined above. | -A Datasource initializer -|| -This is configured to execute the scripts configured via the `batch.drop.script` and -`batch.schema.script` properties. By default, the schema scripts for HSQLDB are executed. -This behavior can be disabled by setting the `batch.data.source.init` property. + A Datasource initializer + || + This is configured to execute the scripts configured via the + `batch.drop.script` and `batch.schema.script` properties. By + default, the schema scripts for HSQLDB are executed. This behavior can be disabled by setting the + `batch.data.source.init` property. | -jobRepository -| -A JDBC based `SimpleJobRepository`. -| -This `JobRepository` uses the previously mentioned data source and transaction -manager. The schema's table prefix is configurable (defaults to BATCH_) via the -`batch.table.prefix` property. + jobRepository + | + A JDBC based `SimpleJobRepository`. + | + This `JobRepository` uses the previously mentioned data source and transaction + manager. The schema's table prefix is configurable (defaults to BATCH_) via the + `batch.table.prefix` property. | -jobLauncher -|`org.springframework.batch.core.launch.support.SimpleJobLauncher`| -Used to launch jobs. + jobLauncher + |`org.springframework.batch.core.launch.support.SimpleJobLauncher`| + Used to launch jobs. | -batchJobOperator -|`org.springframework.batch.core.launch.support.SimpleJobOperator`| -The `JsrJobOperator` wraps this to provide most of it's functionality. + batchJobOperator + |`org.springframework.batch.core.launch.support.SimpleJobOperator`| + The `JsrJobOperator` wraps this to provide most of it's functionality. | -jobExplorer -|`org.springframework.batch.core.explore.support.JobExplorerFactoryBean`| -Used to address lookup functionality provided by the `JsrJobOperator`. + jobExplorer + |`org.springframework.batch.core.explore.support.JobExplorerFactoryBean`| + Used to address lookup functionality provided by the `JsrJobOperator`. | -jobParametersConverter -|`org.springframework.batch.core.jsr.JsrJobParametersConverter`| -JSR-352 specific implementation of the `JobParametersConverter`. + jobParametersConverter + |`org.springframework.batch.core.jsr.JsrJobParametersConverter`| + JSR-352 specific implementation of the `JobParametersConverter`. | -jobRegistry -|`org.springframework.batch.core.configuration.support.MapJobRegistry`| -Used by the `SimpleJobOperator`. + jobRegistry + |`org.springframework.batch.core.configuration.support.MapJobRegistry`| + Used by the `SimpleJobOperator`. | -placeholderProperties -|`org.springframework.beans.factory.config.PropertyPlaceholderConfigure`| -Loads the properties file `batch-${ENVIRONMENT:hsql}.properties` to configure the -properties mentioned above. ENVIRONMENT is a System property (defaults to `hsql`) that -can be used to specify any of the supported databases Spring Batch currently supports. + placeholderProperties + |`org.springframework.beans.factory.config.PropertyPlaceholderConfigure`| + Loads the properties file `batch-${ENVIRONMENT:hsql}.properties` to configure + the properties mentioned above. ENVIRONMENT is a System property (defaults to `hsql`) + that can be used to specify any of the supported databases Spring Batch currently + supports. + + |=============== + + + + + [NOTE] ==== -None of the above beans are optional for executing JSR-352 based jobs. All may be -overridden to provide customized functionality as needed. +None of the above beans are optional for executing JSR-352 based jobs. All may be overridden to +provide customized functionality as needed. ==== [[dependencyInjection]] + + === Dependency Injection -JSR-352 is based heavily on the Spring Batch programming model. As such, while not -explicitly requiring a formal dependency injection implementation, DI of some kind -implied. Spring Batch supports all three methods for loading batch artifacts defined by -JSR-352: +JSR-352 is based heavily on the Spring Batch programming model. As such, while not explicitly requiring a +formal dependency injection implementation, DI of some kind implied. Spring Batch supports all three +methods for loading batch artifacts defined by JSR-352: + * Implementation Specific Loader: Spring Batch is built upon Spring and so supports Spring dependency injection within JSR-352 batch jobs. -* Archive Loader: JSR-352 defines the existing of a batch.xml file that provides mappings -between a logical name and a class name. This file must be found within the /META-INF/ +* Archive Loader: JSR-352 defines the existing of a `batch.xml` file that provides mappings +between a logical name and a class name. This file must be found within the `/META-INF/` directory if it is used. * Thread Context Class Loader: JSR-352 allows configurations to specify batch artifact implementations in their JSL by providing the fully qualified class name inline. Spring @@ -164,7 +180,7 @@ Batch supports this as well in JSR-352 configured jobs. To use Spring dependency injection within a JSR-352 based batch job consists of configuring batch artifacts using a Spring application context as beans. Once the beans have been defined, a job can refer to them as it would any bean defined within the -batch.xml file. +`batch.xml` file. [role="xmlContent"] The following example shows how to use Spring dependency injection within a JSR-352 based @@ -222,14 +238,14 @@ public class BatchConfiguration { ---- -The assembly of Spring contexts (imports, etc) works with JSR-352 jobs just as it would -with any other Spring based application. The only difference with a JSR-352 based job is -that the entry point for the context definition will be the job definition found in /META-INF/batch-jobs/. +The assembly of Spring contexts (imports, etc) works with JSR-352 jobs just as it would with any other +Spring based application. The only difference with a JSR-352 based job is that the entry point for the +context definition will be the job definition found in /META-INF/batch-jobs/. + +To use the thread context class loader approach, all you need to do is provide the fully qualified class +name as the ref. It is important to note that when using this approach or the `batch.xml` approach, the class +referenced requires a no argument constructor which will be used to create the bean. -To use the thread context class loader approach, all you need to do is provide the fully -qualified class name as the ref. It is important to note that when using this approach or -the batch.xml approach, the class referenced requires a no argument constructor which is -used to create the bean. [source, xml] ---- @@ -243,6 +259,8 @@ used to create the bean. ---- [[jsrJobProperties]] + + === Batch Properties [[jsrPropertySupport]] @@ -250,9 +268,9 @@ used to create the bean. ==== Property Support -JSR-352 allows for properties to be defined at the Job, Step and batch artifact level by -way of configuration in the JSL. Batch properties are configured at each level in the -following way: +JSR-352 allows for properties to be defined at the Job, Step and batch artifact level by way of +configuration in the JSL. Batch properties are configured at each level in the following way: + [source, xml] ---- @@ -262,18 +280,22 @@ following way: ---- + `Properties` may be configured on any batch artifact. [[jsrBatchPropertyAnnotation]] + + ==== @BatchProperty annotation `Properties` are referenced in batch artifacts by annotating class fields with the -`@BatchProperty` and `@Inject` annotations (both annotations are required by the spec). As -defined by JSR-352, fields for properties must be String typed. Any type conversion is up -to the implementing developer to perform. +`@BatchProperty` and `@Inject` annotations (both annotations +are required by the spec). As defined by JSR-352, fields for properties must be String typed. Any type +conversion is up to the implementing developer to perform. + +An `javax.batch.api.chunk.ItemReader` artifact could be configured with a +properties block such as the one described above and accessed as such: -An `javax.batch.api.chunk.ItemReader` artifact could be configured with a properties block -such as the one described above and accessed as such: [source, java] ---- @@ -286,13 +308,16 @@ public class MyItemReader extends AbstractItemReader { } ---- + The value of the field "propertyName1" will be "propertyValue1" [[jsrPropertySubstitution]] + + ==== Property Substitution -Property substitution is provided by way of operators and simple conditional expressions. -The general usage is `#{operator['key']}`. +Property substitution is provided by way of operators and simple conditional expressions. The general +usage is `#{operator['key']}`. Supported operators: @@ -314,23 +339,26 @@ used, which are separated by a ';'. [[jsrProcessingModels]] + === Processing Models JSR-352 provides the same two basic processing models that Spring Batch does: * Item based processing - Using an `javax.batch.api.chunk.ItemReader`, an optional `javax.batch.api.chunk.ItemProcessor`, and an `javax.batch.api.chunk.ItemWriter`. -* Task based processing - Using a `javax.batch.api.Batchlet` implementation. This -processing model is the same as the `org.springframework.batch.core.step.tasklet.Tasklet` -based processing currently available. - +* Task based processing - Using a `javax.batch.api.Batchlet` +implementation. This processing model is the same as the +`org.springframework.batch.core.step.tasklet.Tasklet` based processing +currently available. ==== Item based processing -Item based processing in this context is a chunk size being set by the number of items -read by an `ItemReader`. To configure a step this way, specify the `item-count` (which -defaults to 10) and optionally configure the `checkpoint-policy` as item (this is the default). +Item based processing in this context is a chunk size being set by the number of items read by an +`ItemReader`. To configure a step this way, specify the +`item-count` (which defaults to 10) and optionally configure the +`checkpoint-policy` as item (this is the default). + [source, xml] ---- @@ -359,9 +387,10 @@ enough in many cases. Because of this, the spec allows for the implementation of checkpointing algorithm by implementing the `javax.batch.api.chunk.CheckpointAlgorithm` interface. This functionality is functionally the same as Spring Batch's custom completion policy. To use an implementation of `CheckpointAlgorithm`, configure your step with the -custom `checkpoint-policy` as shown below where fooCheckpointer refers to an +custom `checkpoint-policy` as shown below where `fooCheckpointer` refers to an implementation of `CheckpointAlgorithm`. + [source, xml] ---- ... @@ -377,19 +406,22 @@ implementation of `CheckpointAlgorithm`. ---- [[jsrRunningAJob]] + === Running a job The entrance to executing a JSR-352 based job is through the -`javax.batch.operations.JobOperator`. Spring Batch provides our own implementation to -this interface (`org.springframework.batch.core.jsr.launch.JsrJobOperator`). This -implementation is loaded via the `javax.batch.runtime.BatchRuntime`. Launching a +`javax.batch.operations.JobOperator`. Spring Batch provides its own implementation of +this interface (`org.springframework.batch.core.jsr.launch.JsrJobOperator`). This +implementation is loaded via the `javax.batch.runtime.BatchRuntime`. Launching a JSR-352 based batch job is implemented as follows: [source, java] ---- + JobOperator jobOperator = BatchRuntime.getJobOperator(); long jobExecutionId = jobOperator.start("fooJob", new Properties()); + ---- The above code does the following: @@ -403,7 +435,7 @@ components that are bootstrapped are similar to those provided by above, the framework looks in /META-INF/batch-jobs for a file named fooJob.xml and load a context that is a child of the shared context mentioned previously. * Launch the job: The job defined within the context will be executed asynchronously. -The `JobExecution's` ID is returned. +The `JobExecution's` ID will be returned. [NOTE] ==== @@ -413,30 +445,34 @@ All JSR-352 based batch jobs are executed asynchronously. When `JobOperator#start` is called using `SimpleJobOperator`, Spring Batch determines if the call is an initial run or a retry of a previously executed run. Using the JSR-352 based `JobOperator#start(String jobXMLName, Properties jobParameters)`, the framework -always creates a new JobInstance (JSR-352 job parameters are non-identifying). In order to +will always create a new JobInstance (JSR-352 job parameters are non-identifying). In order to restart a job, a call to `JobOperator#restart(long executionId, Properties restartParameters)` is required. - [[jsrContexts]] + === Contexts -JSR-352 defines two context objects that are used to interact with the meta-data of a job -or step from within a batch artifact: `javax.batch.runtime.context.JobContext` and -`javax.batch.runtime.context.StepContext`. Both of these are available in any step-level -artifact (`Batchlet`, `ItemReader`, and others) with the `JobContext` being available to -job-level artifacts as well (JobListener for example). +JSR-352 defines two context objects that are used to interact with the meta-data of a job or step from +within a batch artifact: `javax.batch.runtime.context.JobContext` and +`javax.batch.runtime.context.StepContext`. Both of these are available in any step +level artifact (`Batchlet`, `ItemReader`, etc) with the +`JobContext` being available to job level artifacts as well +(`JobListener` for example). + +To obtain a reference to the `JobContext` or `StepContext` +within the current scope, simply use the `@Inject` annotation: -To obtain a reference to the `JobContext` or `StepContext` within the current scope, use -the `@Inject` annotation, as follows: [source, java] ---- @Inject JobContext jobContext; + ---- + [NOTE] .@Autowire for JSR-352 contexts ==== @@ -444,37 +480,46 @@ Using Spring's @Autowire is not supported for the injection of these contexts. ==== -In Spring Batch, the `JobContext` and `StepContext` wrap their corresponding execution -objects (`JobExecution` and `StepExecution` respectively). Data stored through -`StepContext#persistent#setPersistentUserData(Serializable data)` is stored in the Spring -Batch `StepExecution#executionContext`. +In Spring Batch, the `JobContext` and `StepContext` wrap their +corresponding execution objects (`JobExecution` and +`StepExecution` respectively). Data stored through +`StepContext#setPersistentUserData(Serializable data)` is stored in the +Spring Batch `StepExecution#executionContext`. [[jsrStepFlow]] + + === Step Flow -Within a JSR-352 based job, the flow of steps works similarly as it does within Spring -Batch. However, there are a few subtle differences: +Within a JSR-352 based job, the flow of steps works similarly as it does within Spring Batch. +However, there are a few subtle differences: + + +* Decision's are steps - In a regular Spring Batch job, a decision is a state that does not +have an independent `StepExecution` or any of the rights and +responsibilities that go along with being a full step.. However, with JSR-352, a decision +is a step just like any other and will behave just as any other steps (transactionality, +it gets a `StepExecution`, etc). This means that they are treated the +same as any other step on restarts as well. + +* `next` attribute and step transitions - In a regular job, these are +allowed to appear together in the same step. JSR-352 allows them to both be used in the +same step with the next attribute taking precedence in evaluation. -* Decision's are steps - In a regular Spring Batch job, a decision is a state that does -not have an independent `StepExecution` or any of the rights and responsibilities that go -along with being a full step. However, with JSR-352, a decision is a step just like any -other and will behave just as any other steps (transactionality, it gets a -`StepExecution`, and so on). This means that they are treated the same as any other step -on restarts as well. -* `next` attribute and step transitions - In a regular job, these are allowed to appear -together in the same step. JSR-352 allows them to both be used in the same step with the -next attribute taking precedence in evaluation. * Transition element ordering - In a standard Spring Batch job, transition elements are sorted from most specific to least specific and evaluated in that order. JSR-352 jobs evaluate transition elements in the order they are specified in the XML. + + [[jsrScaling]] + + === Scaling a JSR-352 batch job -<<<<<<< HEAD Traditional Spring Batch jobs have four ways of scaling (the last two capable of being executed across - multiple JVMs): +multiple JVMs): * Split - Running multiple steps in parallel. @@ -496,134 +541,80 @@ JSR-352 provides two options for scaling batch jobs. Both options support only * Partitioning - Conceptually the same as Spring Batch however implemented slightly different. -======= -Traditional Spring Batch jobs have four ways of scaling (the last two capable of being -executed across multiple JVMs): ->>>>>>> Made the "Both" option make sense -* Split: Running multiple steps in parallel. -* Multiple threads: Executing a single step via multiple threads. -* Partitioning: Dividing the data up for parallel processing (master/slave). -* Remote Chunking: Executing the processor piece of logic remotely. -JSR-352 provides two options for scaling batch jobs. Both options support only a single -JVM: -* Split: Same as Spring Batch -* Partitioning: Conceptually the same as Spring Batch however implemented slightly -different. [[jsrPartitioning]] + + ==== Partitioning -<<<<<<< HEAD Conceptually, partitioning in JSR-352 is the same as it is in Spring Batch. Meta-data is provided - to each worker to identify the input to be processed, with the workers reporting back to the manager the - results upon completion. However, there are some important differences: +to each worker to identify the input to be processed, with the workers reporting back to the manager the +results upon completion. However, there are some important differences: * Partitioned `Batchlet` - This will run multiple instances of the - configured `Batchlet` on multiple threads. Each instance will have - it's own set of properties as provided by the JSL or the - `PartitionPlan` +configured `Batchlet` on multiple threads. Each instance will have +it's own set of properties as provided by the JSL or the +`PartitionPlan` * `PartitionPlan` - With Spring Batch's partitioning, an - `ExecutionContext` is provided for each partition. With JSR-352, a - single `javax.batch.api.partition.PartitionPlan` is provided with an - array of `Properties` providing the meta-data for each partition. +`ExecutionContext` is provided for each partition. With JSR-352, a +single `javax.batch.api.partition.PartitionPlan` is provided with an +array of `Properties` providing the meta-data for each partition. * `PartitionMapper` - JSR-352 provides two ways to generate partition - meta-data. One is via the JSL (partition properties). The second is via an implementation - of the `javax.batch.api.partition.PartitionMapper` interface. - Functionally, this interface is similar to the - `org.springframework.batch.core.partition.support.Partitioner` - interface provided by Spring Batch in that it provides a way to programmatically generate - meta-data for partitioning. +meta-data. One is via the JSL (partition properties). The second is via an implementation +of the `javax.batch.api.partition.PartitionMapper` interface. +Functionally, this interface is similar to the +`org.springframework.batch.core.partition.support.Partitioner` +interface provided by Spring Batch in that it provides a way to programmatically generate +meta-data for partitioning. * `StepExecutions` - In Spring Batch, partitioned steps are run as - manager/worker. Within JSR-352, the same configuration occurs. However, the worker steps do - not get official `StepExecutions`. Because of that, calls to - `JsrJobOperator#getStepExecutions(long jobExecutionId)` will only - return the `StepExecution` for the manager. -======= -Conceptually, partitioning in JSR-352 is the same as it is in Spring Batch. Meta-data is -provided to each slave to identify the input to be processed with the slaves reporting -back to the master the results upon completion. However, there are some important -differences: - -* Partitioned `Batchlet`: This runs multiple instances of the configured `Batchlet` on -multiple threads. Each instance has its own set of properties as provided by the JSL or -the `PartitionPlan`. -* `PartitionPlan`: With Spring Batch's partitioning, an `ExecutionContext` is provided -for each partition. With JSR-352, a single `javax.batch.api.partition.PartitionPlan` is -provided with an array of `Properties` providing the meta-data for each partition. -* `PartitionMapper`: JSR-352 provides two ways to generate partition meta-data. One is by -setting the JSL (partition properties). The second is via an implementation of the -`javax.batch.api.partition.PartitionMapper` interface. Functionally, this interface is -similar to the `org.springframework.batch.core.partition.support.Partitioner` interface -provided by Spring Batch in that it provides a way to programmatically generate meta-data -for partitioning. -* `StepExecutions`: In Spring Batch, partitioned steps are run as master/slave. Within -JSR-352, the same configuration occurs. However, the slave steps do not get official -`StepExecutions`. Because of that, calls to -`JsrJobOperator#getStepExecutions(long jobExecutionId)` return only the `StepExecution` -for the master. ->>>>>>> Made the "Both" option make sense +manager/worker. Within JSR-352, the same configuration occurs. However, the worker steps do +not get official `StepExecutions`. Because of that, calls to +`JsrJobOperator#getStepExecutions(long jobExecutionId)` will only +return the `StepExecution` for the manager. [NOTE] ==== The child `StepExecutions` still exist in the job repository and are available -through the `JobExplorer` and Spring Batch Admin. +through the `JobExplorer`. ==== -<<<<<<< HEAD * Compensating logic - Since Spring Batch implements the manager/worker logic of - partitioning using steps, `StepExecutionListeners` can be used to - handle compensating logic if something goes wrong. However, since the workers JSR-352 - provides a collection of other components for the ability to provide compensating logic when - errors occur and to dynamically set the exit status. These components include the following: +partitioning using steps, `StepExecutionListeners` can be used to +handle compensating logic if something goes wrong. However, since the workers JSR-352 +provides a collection of other components for the ability to provide compensating logic when +errors occur and to dynamically set the exit status. These components include the following: |=============== |__Artifact Interface__|__Description__ |`javax.batch.api.partition.PartitionCollector`|Provides a way for worker steps to send information back to the - manager. There is one instance per worker thread. +manager. There is one instance per worker thread. |`javax.batch.api.partition.PartitionAnalyzer`|End point that receives the information collected by the - `PartitionCollector` as well as the resulting - statuses from a completed partition. +`PartitionCollector` as well as the resulting +statuses from a completed partition. |`javax.batch.api.partition.PartitionReducer`|Provides the ability to provide compensating logic for a partitioned - step. - -======= -* Compensating logic - Since Spring Batch implements the master/slave logic of -partitioning using steps, `StepExecutionListeners` can be used to handle compensating -logic if something goes wrong. However, since the slaves JSR-352 provides a collection of -other components for the ability to provide compensating logic when errors occur and to -dynamically set the exit status. These components include the following: +step. |=============== -|__Artifact Interface__|__Description__ -|`javax.batch.api.partition.PartitionCollector`|Provides a way for slave steps to send -information back to the master. There is one instance per slave thread. -|`javax.batch.api.partition.PartitionAnalyzer`|End point that receives the information -collected by the `PartitionCollector` as well as the resulting statuses from a completed -partition. -|`javax.batch.api.partition.PartitionReducer`|Provides the ability to provide compensating -logic for a partitioned step. ->>>>>>> Made the "Both" option make sense -|=============== - [[jsrTesting]] + === Testing -Since all JSR-352 based jobs are executed asynchronously, it can be difficult to determine -when a job has completed. To help with testing, Spring Batch provides the -`org.springframework.batch.core.jsr.JsrTestUtils`. This utility class provides the -ability to start a job and restart a job and wait for it to complete. Once the job -completes, the associated `JobExecution` is returned. +Since all JSR-352 based jobs are executed asynchronously, it can be difficult to determine when a job has +completed. To help with testing, Spring Batch provides the +`org.springframework.batch.test.JsrTestUtils`. This utility class provides the +ability to start a job and restart a job and wait for it to complete. Once the job completes, the +associated `JobExecution` is returned.