GH-1123 - Detect events configured for externalization published outside a transaction

[yunhobb]

Summary

Events configured for externalization via @Externalized silently fail when published outside a transaction context — they are neither persisted nor externalized. This can be difficult to diagnose.

This change adds a warning log in PersistentApplicationEventMulticaster to detect this scenario and inform developers with actionable guidance.

Fixes #1123

Changes

• Add EventExternalizationConfiguration as an optional dependency to PersistentApplicationEventMulticaster with a backward-compatible two-argument constructor overload
• Add detectEventPublishedOutsideTransaction() that logs a warning when:
  1. No active transaction is present
  2. Transactional event listeners exist for the event
  3. The event is configured for externalization
• Wire ObjectProvider<EventExternalizationConfiguration> through EventPublicationConfiguration and EventPublicationAutoConfiguration
• Add Javadoc to TransactionalEventListeners.hasListeners()

Test plan

• 4 new unit tests covering all branches:
  • Warns when externalization event published outside transaction
  • Does not warn inside an active transaction
  • Does not warn for non-externalization events
  • Does not warn when no transactional listeners exist
• All existing module tests pass

[yunhobb]

I added new 3-arg constructor but kept the old 2-arg one to not break existing API. The old one just delegates to new one with disabled config. If you think @deprecated is needed or want different approach, please let me know.

[yunhobb]

The only way to verify this detection is checking log output, so I used Logback ListAppender to capture it. I see this pattern is not used in other tests in this project. If you prefer different way to test this, I'm happy to change.

[yunhobb]

Hi @odrotbohm, 😄

I hope you're doing well! I just wanted to kindly follow up on this PR.

I recently rebased onto the latest main and left a couple of review comments explaining my design decisions — particularly around the backward-compatible constructor overload and the test approach.

I completely understand you have a busy schedule, so there's no rush at all. Whenever you get a chance, I'd really appreciate any feedback — even a quick note on whether the overall direction looks right would be super helpful.

Thank you for your time!