UNKNOWN * additionally prevent restart of step executions with status STARTING, STARTED or STOPPING * additionally prevent restart of job executions with status UNKNOWN or STOPPING
…mpty line are ignored
This commit includes the parent builder's current state from a SplitBuilder in the actual split. The documentation is also updated to note that a user should either create a flow with transitions or a flow that splits, not both and use composition to create more complex flows. BATCH-2346
…Processing and XML namespace
Prior to this commit, the SystemCommandTasklet is able to be stopped only by an external process calling directly into it or updating the instance of the StepExecution it holds onto. This update allows the tasklet to poll the job repository for stop requests in a similar way chunk based processing does. BATCH-2331
While existing functionality provided the ability to override the components provided in the baseContext.xml (as required for JSR-352 functionality) at a job by job level, this commit allows a user to specify a base context for all of the JSR-352 based jobs within a JVM. To set the location of the custom base context, a JVM property JSR-352-BASE-CONTEXT should be set. BATCH-2290
While the JSR-352 provides only one way to access the JobOperator (BatchRuntime.getJobOperator()), it is useful for testing and embedding to be able to wire your own JsrJobOperator instance. This commit addresses previous issues with using the constructor that provided that functionality. Note: This is a breaking change in that there is a new parameter on the non-default constructor (adding a PlatformTransactionManager reference). Users using the JsrJobOperator through the BatchRuntime as previously mentioned should not be impacted. Since this is the *only* method perscribed by the JSR to consume that class, it is not expected to have a large impact. This fix partially addresses BATCH-2290.
contexts scenarios AbstractApplicationContextFactory, when configuring a child context, copies all of the BeanPostProcessors from the parent to the child. Normally this is a good thing. However, in the case of teh ApplicationContextAwareProcessor, the child context ends up with two instances, one for the parent context and one for the child context. This brings two issues to light: 1. Unknown which context is being injected - On beans implementing ApplicationContextAware, it can't be determined which context (the parent or the child) will be injected since both BPPs will be called in an indeterimant order. 2. Errors occur with ApplicationObjectSupport - If the child context contains a bean that extends ApplicationObjectSupport, when the second ApplicationContextAwareProcessor is called, the bean will throw an exception since it is only allowed to be initialized with one application context. This fix adds additional logic to remove the ApplicationContextAwareProcessor from the parent context before adding all the BPPs to the child. This fix addresses BATCH-2319.
BATCH-2159 provides a tweak to the insert statement used for initializing the sequence tables used in the job repository database so that they don't error if run multiple times as well as don't insert multiple rows.
When using java config, the call to SimpleFlow#afterPropertiesSet is not called in all cases as noted in BATCH-2291. This commit updates the builder to explicitly make the call, and updates the SimpleFlow to be idempotent for calls to afterPropertiesSet.
BATCH-2302 documents a scenario where an item throws an exception in a fault tollerant step in the write, then in the process, throws an exception as well. This leads to an infinite loop. To address this, prior to attempting to write items during scanning we need to validate that the there are items to be written (we were not which was causing a NoSuchElementException when we did inputs.next(). This commit also removes an eronous System.out left in the CoreNamespaceUtils.
The SystemCommandTasklet checks a flag to determine if another thread has requested that it be stopped. Since this flag will be set via another thread than the executing thread, it needs to be declared volitile so that it's state is propigated across threads correctly. The documentation for StoppableTasklet has also been upadted to call out that scenario. This commit addresses Jira BATCH-2271
Prior to this commit the initialize method (which is annotated with @PostConstruct) was throwing a checked exception wich goes against the @PostConstruct contract. We now wrap any checked exceptions in a BatchConfigurationException and throw that. This commit fixes (again) BATCH-2276
When using a combination of Java configuration and the XML namespace configuration, prior to this commit, we would add the batch custom scopes twice which lead to issues. This commit gives priority to the custom scopes provided by the java configuration. If you've used @EnableBatchProcessing and have configured batch components using the batch namespace, the custom scopes that come with the java config will take precidence. This commit addresses Jira BATCH-2266
Without this change, when passing an invalid job parameter to a bean that is created internally by Spring Batch will cause a BeanCreationException that is essentially ignored. Due to it being ignored, an infinite loop occurs in processing.
added support for a @JobScope annotation.
…ted in a cloned plan