3.x release notes
3.1.2.RELEASE
3.1.1.RELEASE
Mainly a bugfix release.
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 newDefaultViewElementBuilderContext
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>)
andmap(BiFunction<ViewElementBuilderContext,ViewElement>)
methods added-
supports transforming the actual
ViewElement
type and returns a new builder for the new type
-
-
HtmlViewElementBuilder
implementations has short-handdata()
methods for addingdata-
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 aCloseable
for 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
@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 standardApplicationEventPublisher
-
ParameterizedAcrossEvent
has been deprecated in favour of implementingResolvableTypeProvider
-
@EventName
has been deprecated, use thecondition
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 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
,AcrossModuleBootstrappedEvent
andAcrossContextBootstrappedEvent
now extendAcrossLifecycleEvent
which implements the SpringApplicationEvent
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
, implementAcrossLifecycleListener
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 parentApplicationContext
(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)
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
installers
andextensions
child package -
note: default
AcrossModule
implementations still only scan theconfig
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
tofalse
-
-
@ModuleConfiguration
classes are now only supported in theextensions
package, and no longer looked for inconfig
-
@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
andJackson2ObjectMapperBuilder
are created and exposed -
if Gson on the classpath: a
Gson
object 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
Validator
bean now implementsSmartValidator
directly, allowing@Validated
with group validation to be used -
the
TextViewElementBuilder
now 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 -
MenuSelector
factory methods have been moved from theMenu
toMenuSelector
class -
some rarely used methods on
PathBasedMenuBuilder
,PathBasedMenuItemBuilder
andBuildMenuEvent
have been removed -
BuildMenuFinishedEvent
has been removed, modules requiring this functionality should now register aMenu
post-processor on theBuildMenuEvent
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()
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.
-
-
-
ViewElement
related changes-
all
ViewElementBuilderSupport
extensions now have aconfigure(Consumer<ViewElementBuilder>)
method to use a more fluent API callback approach for additional configuration -
container-like builders support
null
values forViewElement
orViewElementBuilder
-
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 regularWebMvcConfigurer
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
andPrefixingHandlerMappingConfigurer
-
-
websocket support has been added, it is activated automatically:
-
if the required dependencies are on the classpath
-
a
WebSocketConfigurer
orWebSocketMessageBrokerConfigurer
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: replaceacrossWebModule.multipart.auto-configure=false
byspring.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
@AcrossTestConfiguration
and theAcrossTestBuilders
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
-
-