Across core changes

AcrossContext

A new AcrossContextInfrastructureModule is now added to every AcrossContext as the very first module. Like the AcrossContextPostProcessorModule it can be used by other modules as an extension point.

Auto-configuration support

  • across.configuration has been dropped in favour of across-configuration.yml which allows more advanced configuration

Removal of deprecated elements

Several components or methods that were deprecated in previous versions have now been removed. It is best if applications or modules remove the use of deprecated components, before attempting an upgrade.

The following is the list of most notable deprecated elements removed:

Across core

  • @AcrossDepends

    • Using @AcrossDepends for conditional component creation is no longer supported. The presence of this annotation will no longer have any effect on component creation.

  • AcrossModuleSettings and related components

    • Developers are encouraged to use @ConfigurationProperties support as embedded in Spring Boot.

  • @AcrossEventHandler and related components (deprecated since 3.0.0)

    • ParameterizedAcrossEvent: implement as ResolvableTypeProvider instead

    • @Event: replace with @EventListener

    • @EventName: replace with @EventListener(condition="#event.eventName == 'my name'")

    • AcrossEventPublisher: replace with ApplicationEventPublisher

      • the publishAsync() method has been removed entirely

  • StringToDateConverter

    • replace with StringToDateTimeConverter

  • @AcrossCondition

    • Use the regular @ConditionalOnExpression instead. Any previous condition using currentModule can use @'across.currentModule' instead.

  • HikariDataSourceHelper

    • Support is dropped in favour of the Spring Boot DataSourceBuilder and datasource properties.

Across web

  • AcrossWebDynamicServletConfigurer

    • Use a ServletContextInitializer instead. For most cases this would be a FilterRegistrationBean.

  • Table class and related components have been removed

    • Rarely used, only known use was DebugWebModule.

  • PathBasedMenuBuilder.move() and .undoMove() methods

    • Use changeItemPath instead. Implementations should be reviewed, as the behaviour of changeItemPath is slightly different from the previous move().

  • AcrossWebModule methods for configuring views have been removed

    • Custom views configuration can be done by setting property values.

Across test

  • @AcrossTestWebConfiguration, AcrossTestContextConfiguration, AcrossTestWebContextConfiguration

    • Use either AcrossTestBuilders or the separate configuration classes.

The following Across module properties have been modified:

Table 1. Property prefix modifications
Module Old prefix New prefix

Across Web

acrossWebModule

across.web

Extension modules

The ability to extend existing module configuration has been expanded. These features are available on @ModuleConfiguration or through manipulating the ModuleBootstrapConfig through the lifecycle events or prepareForBootstrap().

Deferred configuration

By default additional configurations are added deferred, meaning they will be added after the initial module configuration. It is now possible to explicitly add configuration as non-deferred, before the default module configuration set.

This allows more flexibility when working with conditionals in the original module configurations.

Optional configuration

The ability to label a configuration as optional has been added to @ModuleConfiguration. An optional configuration will not cause the module ApplicationContext to be started.

Skipped bootstrap status

A module with only optional configurations will skip the bootstrapping of its own ApplicationContext. As of Across 5.0.1 these modules will no longer be disabled, but will get a specific bootstrap status: Skipped.

Existing code might break when expecting any enabled AcrossModule to automatically have an ApplicationContext. Consumer code should be adjusted to check for the actual bootstrapping using for example AcrossModuleInfo.isBootstrapped().

Extension module

The above changes make it possible to define a module as an "extension" module. An extension module has a regular module descriptor but only extends other modules with additional configuration.

Use a this approach when you do not require a separate module context for the infrastructure you provide but you do want your code to behave as a separate module with regards to configuration and dependencies.

« Spring Boot upgrade Across core changes Across Hibernate Module »