Skip to content

v0.7.5 — Client Hardening, RFC 9457 Improvements & Docker Refinements

Choose a tag to compare

View all tags
@bsayli bsayli released this 14 Feb 17:00
· 222 commits to main since this release
v0.7.5
b57f9af

Release 0.7.5 is a stabilization and hardening release built on top of the canonical contract baseline introduced in v0.7.4.

While v0.7.4 established the shared api-contract and unified the repository around a single response envelope, v0.7.5 focuses on runtime robustness, error-handling correctness, Docker build quality, and documentation consistency — without changing the canonical contract surface.

✨ Highlights

⬆️ Framework & Tooling Alignment

  • All modules bumped to 0.7.5
  • Spring Boot → 3.5.10
  • OpenAPI Generator → 7.19.0
  • Dependency alignment across server and client modules

🧩 Client: RFC 9457 ProblemDetail Hardening

The customer-service-client now handles non‑2xx responses more defensively and deterministically.

Improvements include:

  • Hardened ProblemDetail extraction

    • status read failures
    • body read failures
    • empty body handling
    • non‑JSON error responses
    • unparsable problem bodies

  • Structured fallback ProblemDetail creation with explicit error codes

  • Contextual extensions.errors for improved diagnostics

  • Explicit client fallback type URNs under:

    urn:customer-service:problem:client-fallback-*

  • Updated tests aligned with stricter, predictable behavior

Outcome:
The generated client behaves consistently even when upstream services return malformed or non‑RFC‑9457 compliant responses.

🌍 Server: Centralized Error Messages & i18n Readiness

Server-side error construction has been cleaned up and centralized.

  • Error titles and details moved to messages.properties
  • Introduced LocalizedMessageResolver
  • Clear separation between message resolution and RFC 9457 problem assembly
  • Consistent construction of errorCode and extensions.errors

Outcome:
Cleaner exception handlers, consistent error payloads, and a production-ready baseline for future localization.

🐳 Docker: Production-Grade Image Refinement

customer-service Docker build upgraded for correctness and cache efficiency:

  • Multi-stage build
  • Maven cache mount for faster rebuilds
  • Spring Boot layered JAR extraction via layertools
  • Non-root runtime user
  • Improved filesystem ownership
  • Better layer reuse across builds

Outcome:
More realistic production container behavior and faster incremental builds.

🧱 api-contract: Quality Refinements

  • Minor refinements and cleanup in ServiceResponse<T>
  • Improved null-handling and default behavior
  • No changes to the canonical { data, meta } contract shape

The response envelope semantics introduced in v0.7.4 remain fully stable.

📚 Documentation & Structural Consistency

  • READMEs refined and aligned with current architecture
  • Adoption guides clarified
  • Contract boundaries and Page-only nested generics rule documented more explicitly
  • CI and publishing workflows adjusted for consistency

This release reduces ambiguity and adoption friction without expanding scope.

🎯 Outcome

  • Canonical contract remains stable (v0.7.4 baseline preserved)
  • Client error handling is significantly more robust
  • Server error handling is cleaner and localization-ready
  • Docker workflows reflect production expectations
  • Documentation better represents architectural guarantees

This is a quality release: stronger defaults, fewer runtime surprises, and clearer boundaries — without expanding the public contract surface.

🧭 Next Steps — 0.8.x Modularization

With v0.7.4, the project reached a stable canonical contract baseline.
With v0.7.5, runtime robustness and structural clarity are reinforced.

The next minor line (0.8.x) will focus on clean modularization and reuse.

Planned 0.8.x Extraction

The remaining implementation will be separated into reusable artifacts while preserving architectural guarantees:

io.github.bsayli:openapi-generics-autoreg

Spring Boot / Springdoc integration:

  • Wrapper registration via OpenApiCustomizer
  • Deterministic schema naming for generics
  • Explicit Page-only nested generics rule

io.github.bsayli:openapi-generics-templates

OpenAPI Generator overlays:

  • Mustache templates for thin wrapper generation
  • Client models extending the canonical contract
  • Generator-safe, version-stable output

All artifacts will share the same 0.8.x version line and remain part of the project family.

0.8.x introduces no new concepts — only separation, reuse, and adoption readiness.

v0.7.5 consolidates the architecture.
v0.8.x will modularize it.

Assets 2
Loading