Polish reference documentation #220
Conversation
…c-… namespace in JDBC-based event support.
…ht profiles. Remove the nesting of the test classes as they will be executed without profiles activated.
…ppet to get started.
A few more comments. Test dependency instead of the core one to include the subsequently shown API.
…ust be public to override interface method.
…ependsOn can be used for beans of different types. I think the author meant @dependsOn not @order annotation.
…oesn't exist. org.springframework.experimental:spring-modulith-observability was the intention.
This reverts commit facbff8.
|
The PR fails because of CI error, artifact not being pushed because of |
src/docs/asciidoc/70-runtime.adoc
Outdated
| @@ -58,7 +58,7 @@ ComponentB --> ComponentA | |||
|
|
|||
| .... | |||
|
|
|||
| While developers could of course define the execution order via Spring's standard `@Order` annotation or `Ordered` interface, Spring Modulith provides an `ApplicationModuleInitializer` interface for beans to be run on application startup. | |||
There was a problem hiding this comment.
Please scratch that. @DependsOn is not a recommended means for ordering user-facing components. @Order/Ordered is exactly what was meant.
There was a problem hiding this comment.
I reverted the wording but I have a question: @Order is mentioned in the context of Application Module Initializers which are intended to be used for different modules, not multiple implementations of the same module:
If a module B depends on module A, the initialization code of A has to run before the one for B, even if the initializers do not directly depend on another.
This is why I think the @Order parallel is confusing as it's intended to order multiple implementations of the same interface while initializers are intended for different modules altogether. Does this make sense?
There was a problem hiding this comment.
I think what plays into this is the fact that for module-specific initialization, you usually want transactional behavior. That's not something you can get with simple components and an @PostConstruct callback in components you'd interconnect via @DependsOn.
In other words, you typically declare an interface for the initializer with a custom method that can be @Transactional and a central component that would depend on List<MyInitializer> and invoke those transactional methods. For that list to be ordered, you'd either use @Order/Ordered. Pretty similar to what we actually implement with ApplicationModuleInitializer.
There was a problem hiding this comment.
@odrotbohm Got it, thank you for the explanation!
odrotbohm
added
in: reference documentation
…type, @dependsOn can be used for beans of different types." This reverts commit fba973e.
…ng-modulith-docs.
…tifact doesn't exist. org.springframework.experimental:spring-modulith-observability was the intention." This reverts commit 1d58923.
odrotbohm
force-pushed
the
main
branch
2 times, most recently
from
de70fe3
to
46127e0
Compare
|
That's squashed and merged, thanks! |
odrotbohm
added
type: improvement
Documenter- to be used before canvases generation code snippet.@DependsOninstead of@Orderbecause@Orderis used in a very specific case when the initialization order of Spring beans of the same type needs to be set.ApplicationModuleInitializermust implementinitialize()method withpublic void initialize()signature.org.springframework.modulith:spring-modulith-observabilityartifact (doesn't exist) toorg.springframework.experimental:spring-modulith-observability.