Narayana: support @DontRollback on exception type

[FroMage]

I need to be able to specify exception types that don't cause a rollback, such as redirect exceptions, for Renarde. This allows me to do it.

[stuartwdouglas]

I think this should also support forcing a rollback (@Rollback(true) and @Rollback(false)).

At the moment rollback happens for unchecked exceptions, and it does not roll back for checked, so we should be able to override both these behaviors.

[FroMage]

OK done.

[stuartwdouglas]

Should this be @inherited ?

[FroMage]

Done

[FroMage]

Done, and added a test.

[quarkus-bot]

This workflow status is outdated as a new workflow run has been triggered.

Failing Jobs - Building 990b2a7

Status	Name	Step	Failures	Logs	Raw logs
✖	Gradle Tests - JDK 11	Build	Failures	Logs	Raw logs

Full information is available in the Build summary check run.

Failures

⚙️ Gradle Tests - JDK 11 #

- Failing: integration-tests/gradle 

📦 integration-tests/gradle

✖ io.quarkus.gradle.devmode.MultiModuleKotlinProjectDevModeTest.main line 22 - More details - Source on GitHub

org.awaitility.core.ConditionTimeoutException: Condition with lambda expression in io.quarkus.test.devmode.util.DevModeTestUtils that uses java.util.function.Supplier, java.util.function.Supplierjava.util.concurrent.atomic.AtomicReference was not fulfilled within 3 minutes.
	at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:164)
	at org.awaitility.core.CallableCondition.await(CallableCondition.java:78)

[FroMage]

Failure seems unrelated, let's restart.

[quarkus-bot]

Failing Jobs - Building 990b2a7

Status	Name	Step	Failures	Logs	Raw logs
✖	Gradle Tests - JDK 11	Build	Failures	Logs	Raw logs
✖	Gradle Tests - JDK 11 Windows	Build	Failures	Logs	Raw logs

Full information is available in the Build summary check run.

Failures

⚙️ Gradle Tests - JDK 11 #

- Failing: integration-tests/gradle 

📦 integration-tests/gradle

✖ io.quarkus.gradle.devmode.MultiModuleKotlinProjectDevModeTest.main line 22 - More details - Source on GitHub

org.awaitility.core.ConditionTimeoutException: Condition with lambda expression in io.quarkus.test.devmode.util.DevModeTestUtils that uses java.util.function.Supplier, java.util.function.Supplierjava.util.concurrent.atomic.AtomicReference was not fulfilled within 3 minutes.
	at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:164)
	at org.awaitility.core.CallableCondition.await(CallableCondition.java:78)

---

⚙️ Gradle Tests - JDK 11 Windows #

- Failing: integration-tests/gradle 

📦 integration-tests/gradle

✖ io.quarkus.gradle.devmode.MultiModuleKotlinProjectDevModeTest.main line 22 - More details - Source on GitHub

org.awaitility.core.ConditionTimeoutException: Condition with lambda expression in io.quarkus.test.devmode.util.DevModeTestUtils that uses java.util.function.Supplier, java.util.function.Supplierjava.util.concurrent.atomic.AtomicReference was not fulfilled within 3 minutes.
	at org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:164)
	at org.awaitility.core.CallableCondition.await(CallableCondition.java:78)

[FroMage]

Same failure, again looks unrelated.

[josephearl]

How does this differ from @Transactional and the dontRollbackOn parameter (which seems more flexible since I can choose to not rollback on exception types that are not under my control)?

[stuartwdouglas]

It is applied to the exception type rather than the interception point. With @transactional if you have 100 endpoints you need to specify dontRollbackOn on every one.

[FroMage]

Yeah. And now I'm realising that I need the same @Rollback annotation for @ReactiveTransactional so I wonder if I duplicate it or create a new module for common annotations or move it to a more core package. WDYT @stuartwdouglas ?

[stuartwdouglas]

I guess a new common module that can be shared.