Grails 4+ with Spring Boot: Minimal Architecture, Trust Boundaries, and Operational Checks

Problem Statement

When upgrading a Grails 3 application to Grails 4 or newer, developers face a shift from the legacy Grails core to Spring Boot. This transition changes the configuration model, dependency resolution, and runtime behavior. The key challenge is to design a lightweight, Spring‑Boot‑native Grails application that respects existing trust boundaries, provides reliable operational checks, and guards against common failure modes.

Requirements

• Java 8+ (Grails 4), Java 11+ (Grails 5), Java 17+ (Grails 6)
• Spring Boot 2.x (for Grails 4/5) or 3.x (for Grails 6)
• Spring Boot starters for web, data, security, and Actuator
• Migration of Config.groovy to application.yml or application.properties
• Operational visibility via /actuator endpoints

Smallest Suitable Design

Starter‑Based Dependency Management

Instead of pulling the full Grails core, the Grails 4+ build uses the grails-boot plugin, which in turn brings in the Spring Boot parent POM. The project’s build.gradle looks like this:

plugins {
    id 'org.grails.grails-web' version '5.3.0'
    id 'org.grails.grails-gorm' version '5.3.0'
    id 'org.springframework.boot' version '2.7.5'
}

With this minimal set, you gain:

• Automatic dependency resolution via Spring Boot starters (e.g., org.springframework.boot:spring-boot-starter-web)
• Embedded Tomcat as the default servlet container
• Spring Boot Actuator for health, metrics, and custom endpoints

Configuration Migration

All Config.groovy entries move to application.yml. For example, a Grails data source configuration:

dataSource {
    dbCreate = "update"
    url = "jdbc:mysql://localhost:3306/mydb"
    username = "user"
    password = "pass"
}

becomes in application.yml:

spring:
  datasource:
    url: jdbc:mysql://localhost:3306/mydb
    username: user
    password: pass
  jpa:
    hibernate:
      ddl-auto: update

Use application-{profile}.yml for environment overrides, matching Spring profiles.

Trust / Data Boundaries

In Grails 3, Config.groovy was a Groovy script that could execute arbitrary code. With application.yml, the configuration is declarative, reducing the attack surface. The boundaries are:

• application.yml – single source of truth for all runtime settings
• Spring profiles – isolated environment settings
• Actuator endpoints – exposed only if explicitly enabled and secured

Operational Checks

Health Endpoint

Run the app (Gradle task bootRun) and hit http://localhost:8080/actuator/health. Expected JSON:

{
  "status":"UP",
  "components":{
    "diskSpace":{"status":"UP"},
    "db":{"status":"UP"}
  }
}

Verify that the db component reports UP after configuring a datasource.

Metrics Endpoint

Access http://localhost:8080/actuator/metrics/jvm.memory.used to confirm JVM metrics collection.

Custom Grails Endpoint

Grails adds a /actuator/grailsController endpoint that exposes controller health. Ensure it returns UP when the application starts.

Failure Modes

Design‑Change Triggers

• Non‑Spring Boot Deployment: If you must package as a WAR for a legacy servlet container, you need to disable the embedded server and configure a ServletContextInitializer.
• Performance Constraints: To avoid Spring's component scanning overhead, explicitly register beans via @Bean methods or use ComponentScan with filters.

Practical Verification Checklist

1. Create a fresh Grails 6 app: grails create-app demo-app
2. Inspect build.gradle for Spring Boot starters
3. Run ./gradlew bootRun and visit health/metrics endpoints
4. Check build/libs/demo-app-*.jar for embedded Tomcat classes
5. Run ./gradlew dependencies --configuration runtimeClasspath to spot duplicates