SpringBoot Common Components

Problem

In many SpringBoot projects, response shapes, exception handling, request tracing, and user context are scattered across controllers and services. This leads to inconsistent API fields, swallowed exceptions, and logs missing requestId. This skill turns those concerns into reusable components, suitable for adding an engineering baseline to an existing project generated by springboot-init.

How It Works

It generates code around Result, GlobalExceptionHandler, UserContext, ShowLogAspect, and ResultAdvice:
- Unified response: adds Result, ResultCode, and RequestUtils so APIs return a standard structure with requestId.
- Exception handling: adds BizException and GlobalExceptionHandler to normalize business errors into failure responses.
- User context: UserContextInterceptor reads x-user-id and x-request-id, then stores them in ThreadLocal for logs and business code.
- AOP logging: @ShowLog with ShowLogAspect prints arguments, return values, latency, and success or exception markers.
- Dependency management: updates pom.xml, chooses javax.servlet or jakarta.servlet based on SpringBoot version, and manages Lombok, Fastjson2, and Commons dependencies.

Boundaries

It depends on the base project structure generated by springboot-init, and artifactId plus packageName are required to locate the project and generate package paths. It is better for completing shared components than replacing project initialization, authentication, or observability. If the project already has response wrappers or interceptors, applying it may create duplicate classes, so package names, configuration classes, and response advice should be reviewed manually.