Across builds on top of Spring framework and tries to stay as compatible as possible. There are some very important differences regarding the
ApplicationContext hierarchy, bean/module ordering and event handling.
Across builds on top of Spring framework and tries to stay as compatible as possible. There are some important differences, however.
Across builds an entire
ApplicationContext hierarchy where every module is its own
ApplicationContext. A medium Across application easily has 5 to 10
ApplicationContext instances. As a simplified comparison: many classic Spring Framework web applications have two
ApplicationContext instances, a Spring Boot application usually has only one.
You can use all features of Spring framework or related libraries in Across applications, but due to the
ApplicationContext hierarchy, sometimes additional setup is required. Beans are only shared between contexts if they are exposed, and a module
ApplicationContext can only access a bean from another module if the other module has already started (unless an Across-specific mechanism like
@PostRefresh is being used).
In a single
ApplicationContext, you cannot rely on any bean ordering unless you set it explicitly. Beans are only considered to be ordered if they have an
@Order annotation, or if they implement the
In an Across application, inter-module ordering must be reliable and is determined by the dependencies that modules have on each other. The actual order of modules is determined at bootstrap time and never changed after. This ordering is used extensively throughout an Across application:
@RefreshableCollectionalways returns the list in module order.
Explicit ordering using the
@Order annotation can be used to order beans regardless of module dependencies. An alternative
@OrderInModule is available if you only want to influence relative ordering of beans within a module.
Across uses its own event bus for publishing events. Events can be published using the
AcrossEventPublisher and handler methods should be annotated with
@Event. Published events will be passed to the handlers in module order: an event handler from module A will be executed before an event handler from module B, if module B has a dependency on A.