# spring-parent: A Java 21 and Spring Boot 4 SDK Collection with a Wide but Uneven Surface

> This review covers the spring-parent repository, a multi-SDK collection for Java 21 and Spring Boot 4.0.1, focusing on its dynamic datasource, Redis, RabbitMQ, tracing, and response wrapping components. The core judgement is that it offers broad utility but with documentation that is often thin and a licensing situation that is unclear.

**mingyang66/spring-parent** — SDKs for dynamic multi-datasource switching, Redis multi-datasource support, full-chain log tracing, RabbitMQ multi-vhost multi-cluster support, logging, tracking-point extensions, entity field masking, i18n, CAPTCHA, a base dev framework, unified exception handling, response wrapping, CORS, API routing, monitoring and route redirection.

- Repository: https://github.com/mingyang66/spring-parent
- Stars: 792 · Forks: 319
- Language: Java
- License: not declared
- Published: 2026-08-21 · Updated: 2026-08-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/mingyang66-spring-parent

## What spring-parent Actually Is

The project is a collection of Spring Boot starter SDKs, not a single application. The README lists at least eleven components: dynamic datasource, Redis multi-datasource, RabbitMQ multi-virtual-host and multi-cluster support, full-link log tracing, a logger component, an extension point for telemetry, entity field desensitization, i18n, captcha, rate limiting, security encryption/decryption, and a base framework with exception handling, response wrapping, CORS, API routing, monitoring, and route redirection. The master branch targets Java 21 and Spring Boot 4.0.1. The README explicitly states that the older Java 11 and Spring Boot 2.7.x code lives in the java11 branch. This is a dual-track project, and you must pick the branch that matches your runtime. The project is distributed through Maven Central under the group ID `io.github.mingyang66`, with a BOM called `emily-dependencies` and a parent POM called `emily-spring-boot-parent`. The version 6.1.2 is the latest release as of August 2026.

## The Response Wrapping Mechanism and Its Config Keys

One of the most concrete components in the README is the response wrapping SDK. It automatically wraps all controller return values into a `BaseResponse` object. The README shows an example JSON response with fields `status`, `message`, `data`, and `spentTime`. The wrapping is enabled by default via `spring.emily.response.enabled=true`. There are two implementation modes: an adapter-based one (`spring.emily.response.enabled-adapter=false` by default) and an AOP advice-based one (`spring.emily.response.enabled-advice=true` by default). This suggests you can choose between a reactive-style adapter or a traditional AOP interceptor. You can exclude specific URLs from wrapping using `spring.emily.response.exclude`, which supports regular expressions. You can also ignore wrapping for a specific method with the `@ApiResponseWrapperIgnore` annotation. The SDK skips wrapping if the return type is already `BaseResponse` or if it is a `byte[]` stream. This is a practical feature for teams that want a uniform API response envelope without writing a global advice themselves. The trade-off is that the wrapping is all-or-nothing unless you configure exclusions, and the README does not explain how the `spentTime` field is calculated or whether it is always present.

## API Path Prefix and CORS: Configuration-Driven Routing

The API routing component lets you add a prefix to all controller paths. The key is `spring.emily.mvc.path.enabled=false` by default, and you can set a custom prefix like `api` with `spring.emily.mvc.path.prefix=api`. There is a `case-sensitive` flag, a `cache-patterns` flag that defaults to null (interpreted as true), and a `trim-tokens` flag. The `use-trailing-slash-match` option defaults to true, meaning both `/a/b/` and `/a/b` are accepted. You can exclude specific controllers with `spring.emily.mvc.path.exclude`. The CORS component is separate, with its own switch `spring.emily.mvc.cors.enable=false`. It supports `allowed-origins`, `allowed-methods`, `allowed-headers`, `allow-credentials`, `exposed-headers`, and `max-age` (default 1800 seconds). A notable limitation: the README says you cannot use `*` in `exposed-headers`. This is a specific constraint that might surprise developers who are used to wildcard patterns. The path prefix component is useful for versioning or for putting an API behind a gateway, but the README does not specify how the prefix interacts with `@RequestMapping` paths that already include a context path.

## Global Filters and Route Redirection: The Gray Release Hook

The README describes a global filter component with a master switch `spring.emily.filter.enabled=true`. There is a `global-switch` that solves the common problem of reading request parameters in a filter and then the controller not receiving them. This is a real issue: if you consume the request body in a filter, the original stream is gone. The component claims to fix that. The route redirection switch is `spring.emily.filter.route-switch=false` by default, and it is described as a gray release routing redirect component. Gray release typically means sending a subset of traffic to a new version. The README does not explain how the routing decision is made, whether it is based on headers, IP ranges, or a percentage. This is a gap. The filter component is a core piece, but without a dedicated README link for it, you have to guess the configuration details beyond the three switches. The fact that the global filter is on by default might interfere with custom filters, so you need to be aware of the ordering.

## The Multi-Datasource and Messaging SDKs: The Heavy Lifters

The repository includes `datasource-spring-boot-starter` for dynamic database switching, `redis-spring-boot-starter` for Redis multi-datasource, and `amqp-spring-boot-starter` for RabbitMQ multi-virtual-host and multi-cluster support. These are the components that justify the project's existence for many teams. The README links to separate usage manuals for each, but the main README does not show any configuration keys for these. That means you must open the sub-READMEs to get started. The descriptions say 'dynamic switching' and 'multi-datasource', which suggests a data-source routing mechanism, likely based on `AbstractRoutingDataSource`, but that is not confirmed from the material. For RabbitMQ, the phrase 'multi-virtual-host multi-cluster support' implies you can define multiple connection factories, each with its own vhost and cluster. This is a common need in microservices that share a RabbitMQ infrastructure. The absence of configuration examples in the main README is a limitation for quick evaluation; you have to trust that the sub-READMEs are complete.

## Tracing, Desensitization, and Other Cross-Cutting SDKs

Beyond data access, the project offers `emily-spring-boot-tracing` for full-link log tracing, `emily-spring-boot-desensitize` for method return value and log desensitization, `emily-spring-boot-i18n` for multilingual translation, `emily-captcha` for graphical captcha, `emily-spring-boot-rateLimiter` for rate limiting, and `emily-spring-boot-security` for encryption and decryption. Each has a linked README. The tracing SDK likely generates a trace ID that propagates across service calls, but the main README does not specify the header name or the propagation mechanism. The desensitization SDK is for masking fields like passwords or phone numbers in logs and responses. The i18n component probably provides message resolution, but the README does not show how to define locales. These SDKs are useful for teams that want a consistent cross-cutting layer without assembling multiple third-party libraries. The risk is that each SDK may have its own configuration style, and the main README does not give a unified view. You have to read each manual separately, which adds to the learning curve.

## Maintenance, License, and Upgrade Considerations

The repository is not archived, and the last push was in August 2026, which suggests active maintenance. The release history shows 6.1.2 in August 2026, 6.1.0 in June 2026, and 5.0.4 in January 2025. The jump from 5.x to 6.x likely includes breaking changes, especially since the master branch targets Spring Boot 4.0.1, which is a major version with its own migration path. The license is listed as unknown. This is a serious concern for enterprise adoption. Without a license file, you cannot legally assume you can use it in commercial products. The README does not mention any license. You must contact the author or check the repository files directly before using it. The maintenance cost is high: because the project covers many areas, you need to track updates across all SDKs. The BOM approach helps with version alignment, but each SDK may have its own release cycle. The documentation is a mix of Chinese and English, with the main README in Chinese. That may be a barrier for non-Chinese-speaking teams.

## Conclusion

Adopt spring-parent if you are building a new Java 21 and Spring Boot 4.0.1 project and need a single dependency that brings dynamic datasources, Redis multi-datasource, RabbitMQ multi-cluster support, and standardized response wrapping. Do not adopt it if you are on Java 11 or Spring Boot 2.7.x, because the master branch is not compatible; you would need the java11 branch, which is a different codebase. Before adopting, verify the license, because the repository does not state one, and confirm that the specific SDK you need has a README with enough detail. Also check the release cadence: 6.1.2 arrived in August 2026, but 5.0.4 was in January 2025, so the project may have breaking changes between major versions. Start by importing the BOM `io.github.mingyang66:emily-dependencies:6.1.2` and test the response wrapping and path prefix components in a small service before committing to the full stack.

## FAQ

### What is the emily-spring-boot-parent artifact?

A Maven parent POM published as io.github.mingyang66:emily-spring-boot-parent at version 6.1.2, whose master branch targets Java 21 and Spring Boot 4.0.1. The Java 11 and Spring Boot 2.7.x line is on a separate java11 branch.

### How do I import the Emily dependency versions?

Through a Maven BOM, by importing io.github.mingyang66:emily-dependencies with type pom and scope import in dependencyManagement. The version shown in the README is 6.1.2.

### Which components ship with this Java framework?

Eleven manuals are linked: a captcha, response and log desensitization, full-link log tracing, multi-datasource, logging, third-party interface calling, i18n, rate limiting, encryption, plus Redis and AMQP starters. The project description also claims Redis multi-datasource, multi-vhost RabbitMQ, monitoring and tracking extension points.

### What does the framework's response wrapper return?

A BaseResponse carrying status, message, data and spentTime. Wrapping is on by default, can be disabled with a property, is skipped for byte array returns and for values already typed as BaseResponse, and can be bypassed per method with an annotation or per path with a property that accepts regular expressions.

### What are the CORS defaults in this framework?

Cross-origin support is off, allowed origins is empty, methods default to GET and POST, allow-credentials is true, exposed headers is empty and cannot use a wildcard, and max-age defaults to 1800 seconds.

### Is the spring-parent repository licensed?

The repository names no license and the root contains no license file. Anyone adopting the parent POM or the BOM should confirm terms with the maintainer first.

## Sources

- [Official README](https://github.com/mingyang66/spring-parent#readme)
- [Project repository](https://github.com/mingyang66/spring-parent)
- [Release notes](https://github.com/mingyang66/spring-parent/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mingyang66-spring-parent