Before this commit, the transaction manager was configurable
at the StepBuilder level, which is inconsistent with the XML
config style in addition to be not needed for most step types.
This commit moves the configuration of the transaction manager
from the StepBuilder down to the AbstractTaskletStepBuilder,
which is the level where the transaction manager is needed.
Resolves#4130
This reverts commit bf2e6ab0e5
as the change was made after spring-framework 6.0.0-M5 was
released. This version is required to release spring-batch
5.0.0-M5
This change will be put back after releasing 5.0.0-M5.
This reverts commit a2cf74ad as the change was made after
spring-kafka 3.0.0-M5 was released. This version is required
to release spring-batch 5.0.0-M5
This change will be put back after releasing 5.0.0-M5.
The side effect is a breaking change in that it will now
throw IllegalStateException instead of the Compare and
AssertExceptions provided by JUnit.
Resolves#4111
Before this commit, the `JobRepositoryTestUtils` was
tied to the JDBC implementation of the `JobRepository`
as it was requiring a datasource. This makes it unusable
with implementations that do not rely on a datasource
to store batch meta-data (A MongoDB job repository for
instance where no datasource is used).
This commit decouples the `JobRepositoryTestUtils` from
the implementation details of the `JobRepository` by making
it working against the `JobRepository` interface.
This commit also introduces the necessary methods in the
`JobRepository` interface as well as various DAOs to
implement the utilities without having to deal with the
details of the underlying repository implementation.
Resolves#4070
Before this commit, trying to register a `JobRepositoryTestUtils` bean
in a test context that contains multiple datasources fails at startup,
because a datasource is autowired in `JobRepositoryTestUtils` while
multiple are defined.
This commit removes the autowiring of the datasource in JobRepositoryTestUtils.
Resolves#4178
The documentation generation change introduced
in #4167 seems to scan more files than previously
WRT checking the code formatting style.
This commit fixes the formatting of the files
that do not conform to the Spring style.
Before this commit, registering the JobLauncherTestUtils
as a bean in the test context (either manually or via
`@SpringBatchTest`) was failing when multiple jobs are
defined in the test context.
This commit removes the autowiring of the job under test
in JobLauncherTestUtils.
Resolves#1237
This commit replaces the usage of List with Chunk
where appropriate. Summary of changes:
- The Chunk class was moved from the `org.springframework.batch.core.step.item` package to the `org.springframework.batch.item` package
- The signature of the method `ItemWriter#write(List)` was changed to `ItemWriter#write(Chunk)`
- All implementations of `ItemWriter` were updated to use the Chunk API instead of List
- All methods in the `ItemWriteListener` interface were updated to use the Chunk API instead of List
- All implementations of `ItemWriteListener` were updated to use the Chunk API instead of List
- The constructor of `ChunkRequest` was changed to accept a Chunk instead of a Collection of items
- The return type of `ChunkRequest#getItems()` was changed from List to Chunk
Resolves#3954
This is to fix the following error:
```
java.lang.NoSuchMethodError: 'org.junit.platform.engine.ConfigurationParameters org.junit.platform.launcher.TestPlan.getConfigurationParameters()'
at org.springframework.kafka.test.junit.GlobalEmbeddedKafkaTestExecutionListener.testPlanExecutionStarted(GlobalEmbeddedKafkaTestExecutionListener.java:91)
at org.junit.platform.launcher.core.TestExecutionListenerRegistry$CompositeTestExecutionListener.lambda$testPlanExecutionStarted$6(TestExecutionListenerRegistry.java:97)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
at org.junit.platform.launcher.core.TestExecutionListenerRegistry.notifyTestExecutionListeners(TestExecutionListenerRegistry.java:59)
at org.junit.platform.launcher.core.TestExecutionListenerRegistry.access$100(TestExecutionListenerRegistry.java:28)
at org.junit.platform.launcher.core.TestExecutionListenerRegistry$CompositeTestExecutionListener.testPlanExecutionStarted(TestExecutionListenerRegistry.java:97)
at org.junit.platform.launcher.core.DefaultLauncher.lambda$execute$6(DefaultLauncher.java:183)
at org.junit.platform.launcher.core.DefaultLauncher.withInterceptedStreams(DefaultLauncher.java:202)
at org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:181)
at org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:128)
at org.apache.maven.surefire.junitplatform.JUnitPlatformProvider.invokeAllTests(JUnitPlatformProvider.java:150)
at org.apache.maven.surefire.junitplatform.JUnitPlatformProvider.invoke(JUnitPlatformProvider.java:124)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:384)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:345)
at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:126)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:418)
```
`org.junit.platform.launcher.TestPlan.getConfigurationParameters()` was
introduced in `junit-platform-launcher:1.8`, and `maven-surefire-plugin`
upgraded to that version in `3.0.0-M6` [1].
[1]: https://issues.apache.org/jira/browse/SUREFIRE-1935
This reverts commit a30aaac4be
which had the side effect of no longer being able to use queries
in `RepositoryItemReader` that return a different type than the
repository's entity type.
Resolves#4164
