A Complete Guide to Multi-Environment Configuration in Spring Boot

In real-world development and deployment, a single project often needs to run in multiple environments (e.g., local, dev, staging, production).
Spring Boot provides a powerful mechanism for environment-based configuration, allowing us to automatically load different settings based on runtime environment variables.

This article walks through how to design a clean and maintainable multi-environment configuration structure step by step.

A Multi-module Maven Project is a software architecture pattern that allows developers to split a large project into multiple interconnected sub-modules, all managed by a single parent project.

This parent-child Maven structure aligns well with microservices architecture. For example, a parent project can contain gateway and auth-service sub-modules. After packaging, these two modules can be deployed and maintained separately.

It’s important to note that this parent-child relationship is for build management, not a functional hierarchy. The parent POM centralizes dependency management, but it doesn’t mean gateway necessarily depends on auth-service.

Programmatic Dependencies: If the gateway module needs to use classes from auth-service, you would add a dependency in its pom.xml. However, in a typical microservices setup, gateway and auth-service communicate via HTTP APIs or OAuth tokens, eliminating the need for a direct JAR dependency.

A typical multi-module project structure in Maven looks like this:

workspace/
 ├─ pom.xml           <-- Parent POM, defines dependencyManagement, pluginManagement, versions
 ├─ gateway/          <-- Child module
 │   └─ pom.xml
 └─ auth-service/     <-- Child module
     └─ pom.xml

In modern application development, secure authentication and authorization are crucial components. This article demonstrates how to implement a Login Service using:

• Spring Boot (REST API, MVC pattern)
• Spring Security + Authorization Server (OAuth2.1)
• MyBatis (database persistence)
• MySQL (user and token storage)

The system acts as:

1. OAuth2 Authorization Server (issue JWT access tokens & refresh tokens).
2. OAuth2 Client (support login with Google in the future).
3. Resource Server validator (other services can validate tokens issued here).

Google的Android在一開始就以Java語言進行開發，這項決定，卻導致長達一年的侵權官司。

由甲骨文起訴Google，原因是Android系統侵犯了甲骨文在Java平台核心的幾項智慧財產權。並且，就在29日晚上，確定Google無法再繼續上訴，必須支付授權費，並禁止使用甲骨文的專利技術。

圖片來源: http://androidcommunity.com/