Page Comparison

New modules

...

• addition: AcrossModuleSettings abstract base class for settings implementation
  • default values for registered properties are now visible in property sources as the very last fallback
  • settings instance will be created when module bootstraps and is available on AcrossModuleInfo and as bean
  • getter/setter properties on the settings for a module can be used in AcrossCondition annotations: eg AcrossCondition("settings.templatesEnabled")
• enhancement: standard property sources no longer take precedence on context or module specific property sources
• enhancement: development mode is now configured on AcrossContext
  • module resource locations can be specified in ${user.home}/dev-configs/across-devel.properties or as individual properties of the form acrossModule.MODULENAME.resources
  • AcrossDevelopmentMode bean can be wired to very verify if development mode is active and to access the development mode properties
• enhancement: bean scanning on refresh has been enhanced
  • use @RefreshableCollection (with parameters) instead of regular @Autowired on collections that should be represented by a RefreshableRegistry
    • annotation parameters can be used to configure the type of registry created
    • wiring will not fail if no beans are found - unlike behavior of default collection autowiring
  • RefreshableRegistry can now also scan for specific generic implementations using a custom ResolvableType
• addition: AcrossContext now creates a CacheManager that defaults to creating NoOp caches
  • cache infrastructure modules can wire the AcrossCompositeCacheManager and add their CacheManager implementation (eg. EhcacheModule)
  • cache utilizing modules can simply wire a CacheManager and assume it is functional
  • default behaviour can be disabled with the disableNoOpCacheManager property
• enhancement: improved event handling, see documentation Across core
  • created default @Event annotation to replace @Handler, @Event supports both @EventName annotations and generic events
    • reduces the need for custom filter specification and the visible tie in to MBassador
  • added ParameterizedAcrossEvent allowing events with generic parameters and handler filtering based on the generic parts

• Status
  colour Yellow title WARNING

   upgraded MBassador dependency to 1.2.0 to support meta @Handler annotations

• Status
  colour Red title breaking change

   by default an AcrossModule now scans the config subpackage instead of the entire module package
  • focuses on keeping configuration classes centralized per module, @ComponentScan on the configuration classes can be used to broaden the scan sope
  • this should also lead to fewer conflicts in testing scenario's when keeping same package structure
  • older modules without custom ApplicationContextConfigurers must now provide their own ComponentScanConfigurer to keep the previous behavior
• addition: default MessageSource bean in modules is now supported (see documentation on Across core)
  • all beans named messageSource defined in a module will be added to the context MessageSource in the order of the modules
  • messageSource beans declared outside the AcrossContext are assumed to be application specific and 
  • example for lookup:
    • first the messageSource from outside context will be queried
    • new then the messageSource from the last module will be used for lookup first and will have the messagesource of the previous module as its parent
  • Across will revert to default Spring messageSource behavior behaviour for messageSource beans annotated as @Internal
• enhancement: Infrastructure and PostProcessor modules now support optional dependencies influencing bootstrap order
  • only optional dependencies of modules with the same role are taken into account
• enhancement: AcrossRole annotation allows an order to be specified
  • modules with the same role will be sorted according to this order before applying dependencies or registration order

...

• ehancement: Spring security filter chain is now registered automatically if an AbstractAcrossServletInitializer is used
  • it is no longer necessary to provide an AbstractSecurityWebApplicationInitializer in this case
• enhancement: bootstrap gives a warning if no MultipartFilter could be detected
  • CSRF protection on multipart file uploads fails unless special care is taken (see also http://docs.spring.io/spring-security/site/docs/current/reference/htmlsingle/#csrf-multipart)
  • when auto configuration of multipart resolving is possible on the AcrossWebModule, this should not be an issue
• addition: default AuditableEntityInterceptor that registers the current SecurityPrincipal on Auditable entities when saving or updating

OAuth2Module

• bugix: avoid IncorrectResultSizeDataAccessExceptionhttps://github.com/spring-projects/spring-security-oauth/issues/276

...