Kai Zander

DataBufferUtils.write(Publisher, Path) loses context

1

Very similar to #27517, but it looks like this issue has not been fixed for the `Path` variant of `DataBufferUtils.write`, the following code (similar to the example snippet from #27517...

This fixes formatting and wording in the threading section.

Missing note about not scoping Step beans with Job scope

2

**Bug description** I have a `Job` that contains a `Step` that is annotated with `@JobScope` (to be able to inject job parameters). Using `JobOperator.stop()` from another thread to stop that...

With virtual threads enabled, long-running `fixedDelay` tasks block `fixedRate` tasks

2

Framework: 6.1.11 Boot: 3.3.2 Reproducer: [demo.zip](https://github.com/user-attachments/files/16662618/demo.zip) As discussed in #31900 and documented in the reference docs, with virtual threads enabled, `fixedDelay` tasks run on a single thread. However, a long-running...

### Proposal With HTTPS enabled (for example by using `@WireMockTest(httpsEnabled = true)`), and a classpath resource named "keystore" present, wiremock fails to start with ``` java.io.IOException: Invalid keystore format at...

Extension is no longer configuring WireMock for default instance due to @EnableWireMock being repeatable

4

### Proposal I'm not sure if the new or the old behaviour is/was correct/intended, but this change broke our tests: With #123, when both a test class and its parent...

RenameSequence on H2 causes validation failure even when change set is excluded by precondition

2

### Search first - [x] I searched and no similar issues were found ### Description The following causes a `ValidationFailedException` when running against H2: ```yaml databaseChangeLog: - changeSet: author: me...

I'm trying to apply the new `FullyQualifiedConfigurationBeanNameGenerator` introduced in 7.0 (see #33448) through `@ComponentScan(nameGenerator = FullyQualifiedConfigurationBeanNameGenerator.class)`, because I want its naming logic to not apply globally, but only for beans...

Fault-tolerant step: `retry(Class)` traverses exception causes, `skip(Class)` does not

2

**Bug description** `skip(Class)` and `retry(Class)` behave inconsistently in that `skip(SkippableException.class)` does _not_ cause `throw new RuntimeException(new SkippableException())` to be skipped, but `retry(SkippableException.class)` _does_ inspect the cause and causes the same...

This is a breaking behaviour change without any benefit imho. While this behaviour has been documented in the method's Javadoc, I don't see the reason behind it: Counting the number...