3.x release notes

3.2.0-SNAPSHOT

Mainly a bugfix release.

Core dependency upgrades

  • Spring Platform Brussels-SR16

  • Spring Framework 4.3.22

  • Spring Boot 1.5.19

Across Core

  • Fixed issue where exposed FactoryBean beans did not behave consistently

    • full target bean and factory type information is now available

  • Fixed issue where exposed Lifecycle beans would get started more than once

Across Web

  • A global ViewElementBuilderContext is now created by default. To revert to the old behaviour set property acrossWebModule.registerGlobalBuilderContext=false.

  • Fixed issue with RequestMenuSelector not selecting the correct items based on a request url with query string parameters

  • Webjar support extended by providing a @webjars path prefix. See default prefixes for more details.

  • Added a more fluent and powerful API for registering Web resources based on view element rendering.

3.1.2.RELEASE

Mainly a bugfix release.

Core dependency upgrades

  • Spring Platform Brussels-SR15

  • Spring Framework 4.3.21

  • Spring Boot 1.5.18

Across Core

  • Deprecated HikariDataSourceHelper in favour of DataSourceBuilder or Spring Boot datasource properties.

Across Web

  • Fixed an issue with thymeleaf output in JSP files using the ThymeleafTag.

3.1.1.RELEASE

Mainly a bugfix release.

Core dependency upgrades

  • Spring Platform Brussels-SR14

  • Spring Framework 4.3.20

  • Spring Boot 1.5.17

Across Web

  • fixed an issue with the automatic registration of a MultipartResolver

  • ViewElementBuilder interface improvements

    • a build() method has been added with a default implementation which will create a new DefaultViewElementBuilderContext is no global context is available

      • the GlobalContextSupportingViewElementBuilder base class has been removed as it was obsolete

    • andThen(ViewElementPostProcessor) method added

      • supports chaining ViewElementPostProcessors on any builder

    • map(Function<ViewElement>) and map(BiFunction<ViewElementBuilderContext,ViewElement>) methods added

      • supports transforming the actual ViewElement type and returns a new builder for the new type

    • HtmlViewElementBuilder implementations has short-hand data() methods for adding data- attributes

  • ViewElementBuilderContext interface improvements

    • findAttribute() methods added that allow looking up an attribute with meta information

      • allows checking if an attribute is present (but possibly null) and if it has been inherited

      • mainly used internally for attribute precedence rules

    • withAttributeOverride() methods added that return a Closeable for temporary overriding of attribute values in a builder context

3.1.0.RELEASE

Core dependency upgrades

  • Spring Platform Brussels-SR11

  • Spring Framework 4.3.18

  • Spring Boot 1.5.14

Across Web

  • path prefixes are now supported directly in redirect view names

    return "redirect:@adminWeb:/somePath";

3.0.0.RELEASE

Across 3.0.0 is a big internal upgrade focused on improving Spring Boot compatibility. Although the number should be limited, this release does introduce some breaking changes.

Across Framework 3.0.0 adds the across-autoconfigure artifact as a base dependency for creating Across applications. It is also the first release with auto-configuration support, see the separate documentation on spring-boot-compatibility.adoc for more details.

Core dependency upgrades

  • Spring Platform Brussels-SR7

  • Spring Framework 4.3.14

  • Spring Boot 1.5.10

Across Core

  • addition of the @ConditionalOnAcrossModule annotation that can be put on a @Configuration class, @Bean method and any @Component to depend on the presence of modules.

    • @AcrossDepends should now only be used on module descriptors, and no longer for conditional component creation

  • internal rewrite of the exposing mechanism: exposed bean definitions are now copied to the module context directly instead of shared via the parent ApplicationContext

    • this improves compatibility with a lot of default Spring related configurations, but might introduce a breaking change for certain modules

  • the event handling system has been overhauled and now uses the default Spring events implementation

    • the custom event bus using MBassador has been removed, as well as the MBassador dependency itself

    • implementing AcrossEvent for your own events is no longer required

    • @Event has been deprecated in favour of the standard @EventListener

    • AcrossEventPublisher has been deprecated in favour of the standard ApplicationEventPublisher

    • ParameterizedAcrossEvent has been deprecated in favour of implementing ResolvableTypeProvider

    • @EventName has been deprecated, use the condition attribute on @EventListener instead

    • Please note that generic event types are handled differently with the new system, where in the past SomeEvent<Object> would have worked, the only working (and more correct) signature is now SomeEvent<? extends Object>

    • parameter-less event listener methods are now possible

    • event listener methods can now also provide return values which will be published as new events

    • ordering event listeners through annotations on a method level is now supported

    • events AcrossModuleBeforeBootstrapEvent, AcrossModuleBootstrappedEvent and AcrossContextBootstrappedEvent now extend AcrossLifecycleEvent which implements the Spring ApplicationEvent directly

      • a utility interface AcrossLifecycleListener has been provided to intercept these common lifecycle events

    • some breaking changes that have been introduced as a result of the refactoring:

      • any uncaught exception in an event listener will now bubble up to the caller and stop the subsequent listeners from being called, instead of just logging the exception and continuing to the next listener

      • manual (de-)registration of event listeners on AcrossEventPublisher is no longer possible

      • bootstrap events can no longer be captured through annotated methods in the parent ApplicationContext, implement AcrossLifecycleListener instead

  • add support for Spring Boot auto-configuration and the META-INF/across.configuration file inside libraries

  • addition of AcrossBootstrapConfigurer that can be used to customize a bootstrapping Across context from a parent ApplicationContext (for example for auto-configuration classes)

  • bean definition names generated for @Configuration or manually registered annotated classes (without @Component) are now always based on the fully qualified class name

    • in rare cases this could introduce a breaking change where configuration instances are wired by name as beans, in this case providing an explicit name for the configuration should fix the problem

  • it’s now possible to explicitly exclude annotated classes to be loaded as module extension during bootstrap configuration

  • the default module scanning packages will now always be kept if you add additional packages on either @EnableAcrossContext or @AcrossApplication

    • if you explicitly want to exclude the default packages you should add . (dot) as a package name to the list

  • Bean Validation 1.1 method validation is now automatically enabled in every Across module if a JSR-303 implementation (eg. Hibernate validator) is on the classpath

  • the TransactionManagementConfigurer helper class has been removed from the core artifact

    • modules should provide their own implementation when necessary

  • ComponentScanConfigurer.forAcrossModule(Class) and ComponentScanConfigurer.forAcrossModulePackage(String) helper functions have been added to create default configurations for modules wishing to scan their entire root package

    • these will correctly exclude the installers and extensions child package

    • note: default AcrossModule implementations still only scan the config child package, this behaviour has not changed

  • failure analyzers have been added to provide better exception information when using @AcrossApplication

  • added support for META-INF/across.configuration

    • allows for externalizing compatibility rules with regular Spring Boot auto-configuration

    • allows for defining illegal use of configuration classes, this can help in avoiding bad use of regular Spring Boot configurations in an Across context

  • added illegal configuration detection on a @AcrossApplication, upon starting the presence of configuration classes will be detected and possibly result in an exception describing the illegal use

    • on by default, it can be disabled explicitly by setting across.configuration.validate to false

  • @ModuleConfiguration classes are now only supported in the extensions package, and no longer looked for in config

    • @ModuleConfiguration is now always a configuration class as well (has @Configuration as meta-annotation)

    • the implementation of @ModuleConfiguration has changed, they are now imported as regular configurations, with full support for conditionals

      • in rare cases this might lead to problems as these configuration classes are imported at a different point in time, usually before the addition of regular annotated classes added to the module

  • @InstallerMethod methods now support arguments, much like a @Autowired or @PostRefresh method

    • the arguments will be fetched from the ApplicationContext when the method is executed

Across Web

A lot of internal configuration has been modified to use out-of-the-box Spring Boot configuration classes instead of customized versions.

The following changes and additions are included in the update:

  • a RestTemplateBuilder is created and exposed

  • Jackson ObjectMapper and Jackson2ObjectMapperBuilder are created and exposed

  • if Gson on the classpath: a Gson object is created and exposed

  • support for across-web/basic-features/error-pages.adoc is now automatically activated

  • the Thymeleaf Java 8 Time dialect is now also included and enabled

  • the default mvc Validator bean now implements SmartValidator directly, allowing @Validated with group validation to be used

  • the TextViewElementBuilder now supports a across-web/web-views/localized-text.adoc as text value

  • several changes to the menu building infrastructure, some breaking. See the across-web/web-views/working-with-menus.adoc for use case examples.

    • added Menu.builder() for easy ad-hoc creation of a menu using path registration

    • MenuSelector factory methods have been moved from the Menu to MenuSelector class

    • some rarely used methods on PathBasedMenuBuilder, PathBasedMenuItemBuilder and BuildMenuEvent have been removed

    • BuildMenuFinishedEvent has been removed, modules requiring this functionality should now register a Menu post-processor on the BuildMenuEvent instead

    • renamed methods on BuildMenuEvent:

      • setSelector() → setMenuSelector(), getSelector() → getMenuSelector()

      • forMenu() → isForMenuOfType()

    • options to customize a menu have been improved and some new ones have been added:

      • on a menu builder these are changeItemPath(), removeItems(), optionalItem() and withProcessor()

      • on a menu item builder these are changePathTo(), remove() and comparator()

      • the unreliable move() method for menu items has been deprecated, use the new changeItemPath() or item().changePathTo() instead

      • using PathBasedMenuBuilder.andThen() it is now possible to register and apply additional configuration after all initial configuration has been done. This is especially useful if you want to make changes to a menu builder when you want to be sure all intial items have been added.

  • ViewElement related changes

    • all ViewElementBuilderSupport extensions now have a configure(Consumer<ViewElementBuilder>) method to use a more fluent API callback approach for additional configuration

    • container-like builders support null values for ViewElement or ViewElementBuilder

      • these will safely be ignored and never added to the children of a container

      • this makes it easier to keep a fluent API style

  • PrefixingHandlerMappingConfigurer can no longer be applied to the default AcrossWebModule, use a regular WebMvcConfigurer to add interceptors

    • different prefixed handler mappings (eg. AdminWebModule) still require the use of PrefixingHandlerMappingConfigurer for adding interceptors

    • if you want to add an interceptor to all controllers, you should implement both WebMvcConfigurer and PrefixingHandlerMappingConfigurer

  • websocket support has been added, it is activated automatically:

    • if the required dependencies are on the classpath

    • a WebSocketConfigurer or WebSocketMessageBrokerConfigurer bean is provided by any module

    • using @EnableWebSocket or @EnableWebSocketMessageBroker anywhere will result in a bootstrap failure, it’s usually enough to just remove these annotations and leave the rest of your code as is

  • the multipart configuration now uses the spring.http.multipart.* properties from Spring Boot (MultipartProperties class)

    • the acrossWebModule.multipart.* settings have been removed: replace acrossWebModule.multipart.auto-configure=false by spring.http.multipart.enabled=false

New module extension support

Extension configuration classes that can now be added to AcrossWebModule:

  • RestTemplateCustomizer

  • HttpMessageConverter

  • Jackson2ObjectMapperBuilderCustomizer

Changes in servlet and filter registration

Filters and servlets are registered in a slightly different fashion than in previous versions. Any Servlet or Filter bean will now be automatically be exposed and registered. If there is an actual registration bean for the filter or servlet, it will take precedence.

The new approach might introduce breaking changes with applications that do not use an embedded application context. The AcrossWebDynamicServletConfigurer is fully deprecated and any beans of that type created in the parent context will not be executed any longer in a non-embedded configuration.

Also the ordering of filters might have changed slightly, modules providing filters should review the order assignment.

Dynamically registered filters should preferably include an explicit order value and should be done inside the Across context (inside a module) and not on the application configuration level.

Across Test

  • new features for exposing additional components during the scope of a test

    • both @AcrossTestConfiguration and the AcrossTestBuilders now have an attribute/method to easily expose additional classes for the scope of the test

    • @ExposeForTest can be used in combination with @SpringBootTest

      • the latter is particularly useful for integration testing of a dynamic application module