Skip to main content

v5.2.0 (2026-09-12)

Scope

  • Core annotation-based AOP and logging, Config auto-configuration, Web response rendering and static resources, and Boot startup and health checks.

Changes

  • Added
    • Unified application startup: The new hasor-boot module starts ordinary and Web applications through Boot.run(args, sources); supports configuration files and property overrides, with runtime extensions through the BootExtension SPI.
    • Default response rendering: Action object results are rendered as JSON and string results as text without per-Action rendering annotations. Configuration can replace the default engines or select none for manual response handling.
    • JSON engine selection: Detects runtime libraries in the order Jackson, Gson, Fastjson, then Fastjson2. Accepts custom ObjectMapper, Gson, or Fastjson-family serialization settings.
    • Resource registration API: WebApiBinder.addResource(path, loaders...) combines multiple resource sources for one path. ResourceBinder configures welcome files, route fallbacks, caching, excluded paths, and matching order.
    • Health checks: Boot Web provides /health by default, with a configurable path and enable switch. Register HealthCheck implementations through @Bean or binding APIs. All checks passing produces UP / 200; any failed check or exception produces DOWN / 503, without exposing exception details.
    • Redirect status codes: @RedirectTo supports 301, 302, 303, 307, and 308. The default remains 302; use forms such as @RedirectTo(301).
  • Improved
    • Built-in annotation AOP: Core configures @Aop support by default, without requiring Config.
    • Unified scanning: ConfigurationModule uses Core's scanning scope and dispatches a single scan to configuration-class and Web-mapping processors. Use auto() for scanning or of(...) for explicit configuration classes.
    • Route registration checks: Automatic scanning reuses registered types and detects conflicting routes, including routes differing only in path-parameter names.
    • Built-in rendering pipeline: Return-value rendering is integrated into request execution rather than configured as a plugin or business filter. Encoding follows Web configuration or the current request, while Actions can override individual responses.
    • Independent resource handling: Actions match first; otherwise static resources are handled outside Hasor business filters and return-value rendering. Supports HEAD and Last-Modified conditional requests.
    • Startup lifecycle: Web joins the unified Boot entry point through an extension, coordinating the application context, embedded server, startup-failure cleanup, and shutdown hooks. Tomcat, Jetty, and Undertow share configuration and can initialize a Web context without an HTTP listener.
    • Consistent framework logging: Related Core and Web logging uses Cobble; business code does not need to change its logging API.
    • Documentation: Expanded Chinese and English guides and historical release notes, with consistent navigation, titles, and version variables in examples.
  • Fixed
    • Prevented additional rendering for manually handled, asynchronous, committed, 204, and 304 responses.
    • Corrected early executable-archive logging when logging dependencies are not yet available, preventing logging from disrupting startup.
    • Corrected directory resource URL resolution when nested JARs lack explicit directory entries.

Upgrade notes

  • Auto-configuration entry point: Replace references to AutoConfigurationModule, WebAutoConfigurationModule, and the old net.hasor.config.core.ConfigurationModule with net.hasor.config.ConfigurationModule. Use ConfigurationModule.of(...) for explicit classes. Scanning now uses hasor.loadPackages; the former autoScan and scanPackages settings under hasor.config, including their Web counterparts, are no longer used.
  • Default rendering behavior: Action results without an explicit rendering mode are now written automatically. Override hasor.render.defaults.objectEngine and stringEngine, or set either to none to disable that automatic output. Default JSON rendering requires at least one supported JSON library; alternatively, register a custom engine.
  • Resource registration migration: Replace ResourceFilter, ResourceHandlerRegistry, and ResourceHandlerRegistration with addResource(...). WebMvcConfigurer.addResourceHandlers now accepts WebApiBinder. Review access control for resources previously protected by Hasor business filters; those filters no longer run for resource requests.
  • Package changes: ForwardTo and RedirectTo move from net.hasor.web.objects to net.hasor.web.render; JsonRenderEngine moves to its json subpackage. CORS classes reside in net.hasor.config.web.cors, and JsonRenderConfigurer in net.hasor.config.web.render. Remove explicit registration of RenderWebPlugin; update explicit references to AOP implementation classes to net.hasor.core.aop.
  • Embedded server configuration: Replace hasor.http.host/port with hasor.boot.web.connectors.http.host/port, and hasor.http.contextPath with hasor.boot.web.server.contextPath. Host and port environment variables remain unchanged; the context-path variable is now HASOR_WEB_CONTEXT_PATH.
  • Container dependencies: Container selection through hasor.http.server or HASOR_HTTP_SERVER is removed. A Web application must have exactly one WebServerProvider implementation; zero or multiple providers cause startup to fail.
  • Health endpoint: Configure hasor.boot.web.health.enabled and hasor.boot.web.health.path as needed, and review endpoint exposure during deployment. Check names come from Bean binding names, falling back to binding IDs.