3.x release notes
3.2.1.RELEASE
This release only has configuration changes related to the artifact repositories present in the standard-module-bom.
3.2.0.RELEASE
Several bugs fixed and some web related features added.
Additional dependencies for JUnit 5
The standard-module-bom has been extended with dependencies for JUnit 5.
These include:
-
org.junit.jupiter:junit-jupiter-engine:5.4.2 -
org.junit.vintage:junit-vintage-engine:5.4.2 -
org.mockito:mockito-junit-jupiter:2.27.0 -
com.github.sbrannen:spring-test-junit5:1.4.0
Modules or applications that wish to use JUnit 5 with this version of Across should add these dependencies in test scope.
If you want to use Mockito with JUnit 5, you should also explicitly use mockito-core with the same version as mockito-junit-jupiter.
The spring-test-junit5 dependency is not available on Maven central.
Add the Jitpack repository to your pom.xml if you cannot fetch it:
<repositories>
<repository>
<id>jitpack.io</id>
<url>https://jitpack.io</url>
</repository>
</repositories>
| Use maven 3.5.0 or higher if you want to use JUnit 5. |
Across Core
-
Fixed issue where exposed
FactoryBeanbeans did not behave consistently-
full target bean and factory type information is now available
-
-
Fixed issue where exposed
Lifecyclebeans would get started more than once
Across Web
-
A global
ViewElementBuilderContextis now created by default. To revert to the old behaviour set propertyacrossWebModule.registerGlobalBuilderContext=false. -
Fixed issue with
RequestMenuSelectornot selecting the correct items based on a request url with query string parameters -
Added a
@webjarsprefix for linking to Webjars content. See Webjars support for more details. -
Added a more fluent and powerful API for registering Web resources based on view element rendering.
3.1.2.RELEASE
3.1.1.RELEASE
Mainly a bugfix release.
Across Web
-
fixed an issue with the automatic registration of a
MultipartResolver -
ViewElementBuilderinterface improvements-
a
build()method has been added with a default implementation which will create a newDefaultViewElementBuilderContextis no global context is available-
the
GlobalContextSupportingViewElementBuilderbase class has been removed as it was obsolete
-
-
andThen(ViewElementPostProcessor)method added-
supports chaining
ViewElementPostProcessorson any builder
-
-
map(Function<ViewElement>)andmap(BiFunction<ViewElementBuilderContext,ViewElement>)methods added-
supports transforming the actual
ViewElementtype and returns a new builder for the new type
-
-
HtmlViewElementBuilderimplementations has short-handdata()methods for addingdata-attributes
-
-
ViewElementBuilderContextinterface 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 aCloseablefor temporary overriding of attribute values in a builder context
-
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 for more details.
Across Core
-
addition of the
@ConditionalOnAcrossModuleannotation that can be put on a@Configurationclass,@Beanmethod and any@Componentto depend on the presence of modules.-
@AcrossDependsshould 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
AcrossEventfor your own events is no longer required -
@Eventhas been deprecated in favour of the standard@EventListener -
AcrossEventPublisherhas been deprecated in favour of the standardApplicationEventPublisher -
ParameterizedAcrossEventhas been deprecated in favour of implementingResolvableTypeProvider -
@EventNamehas been deprecated, use theconditionattribute on@EventListenerinstead -
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 nowSomeEvent<? 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,AcrossModuleBootstrappedEventandAcrossContextBootstrappedEventnow extendAcrossLifecycleEventwhich implements the SpringApplicationEventdirectly-
a utility interface
AcrossLifecycleListenerhas 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
AcrossEventPublisheris no longer possible -
bootstrap events can no longer be captured through annotated methods in the parent
ApplicationContext, implementAcrossLifecycleListenerinstead
-
-
-
add support for Spring Boot auto-configuration and the
META-INF/across.configurationfile inside libraries -
addition of
AcrossBootstrapConfigurerthat can be used to customize a bootstrapping Across context from a parentApplicationContext(for example for auto-configuration classes) -
bean definition names generated for
@Configurationor 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
@EnableAcrossContextor@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
TransactionManagementConfigurerhelper class has been removed from the core artifact-
modules should provide their own implementation when necessary
-
-
ComponentScanConfigurer.forAcrossModule(Class)andComponentScanConfigurer.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
installersandextensionschild package -
note: default
AcrossModuleimplementations still only scan theconfigchild 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.validatetofalse
-
-
@ModuleConfigurationclasses are now only supported in theextensionspackage, and no longer looked for inconfig-
@ModuleConfigurationis now always a configuration class as well (has@Configurationas meta-annotation) -
the implementation of
@ModuleConfigurationhas 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
-
-
-
@InstallerMethodmethods now support arguments, much like a@Autowiredor@PostRefreshmethod-
the arguments will be fetched from the
ApplicationContextwhen 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
RestTemplateBuilderis created and exposed -
Jackson
ObjectMapperandJackson2ObjectMapperBuilderare created and exposed -
if Gson on the classpath: a
Gsonobject is created and exposed -
support for default error pages is now automatically activated
-
the Thymeleaf Java 8 Time dialect is now also included and enabled
-
the default mvc
Validatorbean now implementsSmartValidatordirectly, allowing@Validatedwith group validation to be used -
the
TextViewElementBuildernow supports a localized text pattern as text value -
several changes to the menu building infrastructure, some breaking. See the updated documentation for use case examples.
-
added
Menu.builder()for easy ad-hoc creation of a menu using path registration -
MenuSelectorfactory methods have been moved from theMenutoMenuSelectorclass -
some rarely used methods on
PathBasedMenuBuilder,PathBasedMenuItemBuilderandBuildMenuEventhave been removed -
BuildMenuFinishedEventhas been removed, modules requiring this functionality should now register aMenupost-processor on theBuildMenuEventinstead -
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()andwithProcessor() -
on a menu item builder these are
changePathTo(),remove()andcomparator() -
the unreliable
move()method for menu items has been deprecated, use the newchangeItemPath()oritem().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.
-
-
-
ViewElementrelated changes-
all
ViewElementBuilderSupportextensions now have aconfigure(Consumer<ViewElementBuilder>)method to use a more fluent API callback approach for additional configuration -
container-like builders support
nullvalues forViewElementorViewElementBuilder-
these will safely be ignored and never added to the children of a container
-
this makes it easier to keep a fluent API style
-
-
-
PrefixingHandlerMappingConfigurercan no longer be applied to the default AcrossWebModule, use a regularWebMvcConfigurerto add interceptors-
different prefixed handler mappings (eg. AdminWebModule) still require the use of
PrefixingHandlerMappingConfigurerfor adding interceptors -
if you want to add an interceptor to all controllers, you should implement both
WebMvcConfigurerandPrefixingHandlerMappingConfigurer
-
-
websocket support has been added, it is activated automatically:
-
if the required dependencies are on the classpath
-
a
WebSocketConfigurerorWebSocketMessageBrokerConfigurerbean is provided by any module -
using
@EnableWebSocketor@EnableWebSocketMessageBrokeranywhere 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 (MultipartPropertiesclass)-
the
acrossWebModule.multipart.*settings have been removed: replaceacrossWebModule.multipart.auto-configure=falsebyspring.http.multipart.enabled=false
-
Extension configuration classes that can now be added to AcrossWebModule:
-
RestTemplateCustomizer -
HttpMessageConverter -
Jackson2ObjectMapperBuilderCustomizer
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
@AcrossTestConfigurationand theAcrossTestBuildersnow have an attribute/method to easily expose additional classes for the scope of the test -
@ExposeForTestcan be used in combination with@SpringBootTest-
the latter is particularly useful for integration testing of a dynamic application module
-
-