The default propagation type of @Transactional is Propagation.REQUIRED. That, however would reuse the already running committed transaction which is not the correct behavior.
Related ticket: #80.
We now register a default customizer on the Scenario instances created to pick up an ExecutorService defined in the ApplicationContext so that customizations made to that are considered in the test execution.
Switch verification of mock beans as Mockito 5.3.0 uses a different MockMaker by default that doesn't add the explicit interface we have previously checked for.
Remove obsolete init- and destroy method declarations from service bean definitions in examples.
We now opt out of defining bean definitions for MongoTransactionManager and TransactionTemplate if user defined. We also make sure to run before the EnableTransactionManagementConfiguration to make sure that will see our auto-configured MongoTransactionManager.
As the Event Publication registry only works in transactional environments, we should enable them for MongoDB by default. This will require a replica setup for the MongoDB instance the application interacts with.
We now avoid accessing the ApplicationContext from a BeforeAllCallback as this might cause the context initialization before other extensions had time to kick in.
We now properly check whether one of a Spring bean's implemented interfaces is exposed by the module before including it in the default rendering of the Application Module Canvas.
The dedicated annotation allows using Scenario as test parameter in @SpringBootTest-based integration tests, too.
ScenarioParameterResolver now throws a better error message if a TransactionTemplate bean is missing from the ApplicationContext.
AbstractApplicationEventMulticaster.supportsEvent(…) currently doesn't properly match unresolved, generic ApplicationEvents (see [0]). We now work around this problem by additionally matching the raw event types in a custom override of supportsEvent(…).
[0] https://github.com/spring-projects/spring-framework/issues/30399
We now register default groupings for the architectural abstractions [0] in case they are available on the classpath but still fall back to the standard Spring Framework ones if not. In other words, if you e.g. use the jmolecules-hexagonal-architecture ones, types and packages annotated with @Port will cause the affected types to appear under a "Ports" section in the "Spring components" row in the Application Module Canvas.
[0] https://github.com/xmolecules/jmolecules#available-libraries-1
We now avoid to initialize the EventPublicationRegistry in the ApplicationEventMulticaster unless there is a transactional event listener interested in the event to be published. This should help us avoid premature initialization of the registry for application events published early in the application context bootstrap phase.
The previous modularity verification arrangement assumed the default module detection strategy to be used. To properly support alternative implementations during the verification we now use a dedicated SliceAssignment implementation that assigns types to slices identified by the module they are located in.
Type based named interfaces on types declared in a module's API package still caused the type to be included in the unnamed interface. This is now fixed by explicitly removing named interface types from the unnamed interface.
We now also detect API package types assigned to a named interface without an explicit name as the package name defaulting doesn't work in this case.
Furthermore, named interfaces are now sorted alphabetically to make the unnamed one always appear first.
We now provide a ScenarioCustomizer that can be used to prepare Scenario instances for test methods with a common customizer. This avoids the need to call ….customize(…) for all Scenarios declared in a test class with the same logic.
Both package- and type-level declarations now use the local package name as the named interface's name. This allows to, at the same time, easily declared named interfaces based on packages but also a nice decoupling of the interface definition and the package layout as individual types can be assigned to such interfaces no matter where they are actually declared.
We now use Spring Test Context's TestContextAnnotationUtils to lookup the @ApplicationModuleTest annotation to eventually bootstrap an ApplicationModules instance. That ensures that we find the annotation on JUnit 5's @Nested classes.
Altered the bean definition to rather only refer to a ListableBeanFactory and only lookup the ApplicationModulesRuntime and ApplicationModuleListeners when the ApplicationStartedEvent is handled.
