Upgrade Spring Boot from 2.6.3 to 3.4.5

[devin-ai-integration]

Summary

Incrementally upgrades Spring Boot from 2.6.3 to 3.4.5, following the recommended one-version-at-a-time approach. All 68 tests pass at each intermediate version. The upgrade path:

2.6.3 → 2.7.18 → 3.0.13 → 3.1.12 → 3.2.12 → 3.3.7 → 3.4.5

Key Changes

Component	Before	After
Spring Boot	2.6.3	3.4.5
Java	11	17
Gradle	7.4	8.12
DGS GraphQL	4.9.21	9.1.2
DGS Codegen	5.0.6	6.3.0
MyBatis	2.2.2	3.0.4
JJWT	0.11.2	0.12.6
Flyway	(managed)	9.22.3 (pinned)
SQLite JDBC	3.36.0.3	3.47.1.0
Rest-Assured	4.5.1	5.5.0
Joda-Time	2.10.13	2.13.0
Spotless	6.2.1	6.25.0
Spring Dep Mgmt	1.0.11.RELEASE	1.1.7
GitHub Actions	checkout/setup-java/cache v2	v4

Breaking Changes Resolved

• Jakarta namespace migration: All javax.validation.* → jakarta.validation.*, javax.servlet.* → jakarta.servlet.* (21 files)
• Spring Security 6.x: WebSecurityConfigurerAdapter removed → SecurityFilterChain bean; antMatchers → requestMatchers; deprecated chaining API → lambda DSL
• JJWT 0.12.x API: setSubject() → subject(), setExpiration() → expiration(), parserBuilder().setSigningKey() → parser().verifyWith(), parseClaimsJws() → parseSignedClaims(), getBody() → getPayload()
• DGS GraphQL: DataFetcherExceptionHandler.onException() → handleException() (returns CompletableFuture); graphql.relay.DefaultPageInfo → DGS-generated PageInfo type
• Spring Framework 6.x: handleMethodArgumentNotValid signature: HttpStatus → HttpStatusCode
• CI Workflow: Updated actions/checkout, actions/setup-java, actions/cache from v2 → v4; JDK 11 → 17

Review & Testing Checklist for Human

• Verify the application starts correctly with ./gradlew bootRun and responds to REST API requests (e.g., POST /users, GET /articles)
• Test GraphQL endpoint at /graphql with a sample query to confirm DGS integration works
• Verify JWT authentication flow end-to-end (register user → login → use token for authenticated endpoints)
• Check Flyway migration runs cleanly on a fresh database (./gradlew clean bootRun)
• Confirm no deprecated API warnings remain in build output (./gradlew compileJava --warning-mode=all)

Notes

• Each upgrade step is preserved as a separate commit for traceability (7 commits total)
• javax.crypto.* imports were intentionally kept — these are JDK classes, not Jakarta EE
• Flyway is pinned to 9.22.3 because Flyway 10+ moved SQLite support to a community module
• Rest-Assured uses enforcedPlatform BOM to prevent Spring Boot's dependency management from downgrading transitive artifacts
• Snyk security check failure is marked as optional; the flagged vulnerability should be reviewed separately

Link to Devin session: https://app.devin.ai/sessions/30ba801fa5684a7d87f2c943721d014d
Requested by: @travismyers-png

---

Devin Review

Status	Commit
⚪ Not started	—

Run Devin Review

💡 Connect your GitHub account to enable automatic code reviews.

---

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment and CI monitoring

[devin-ai-integration]

Devin Review found 1 potential issue.

View 7 additional findings in Devin Review.

[devin-ai-integration]

🔴 Flyway 9.22.3 is incompatible with Spring Boot 3.4.5 which requires Flyway 10.x

Spring Boot 3.4.5's FlywayAutoConfiguration is designed for Flyway 10.x. The build.gradle explicitly pins flyway-core:9.22.3, which downgrades from the Spring Boot-managed version (10.x). Starting in Spring Boot 3.2, the Flyway auto-configuration was updated to use Flyway 10 APIs (e.g., new FluentConfiguration methods like failOnMissingLocations()). Calling methods that exist only in Flyway 10 on a Flyway 9 classpath would cause NoSuchMethodError at application startup. The likely motivation for pinning 9.22.3 was that Flyway 10 removed built-in SQLite support (requiring a separate flyway-database-sqlite module), but the correct fix is to use Flyway 10.x and add the appropriate database module dependency.

Prompt for agents

The build.gradle pins flyway-core to 9.22.3, but Spring Boot 3.4.5 expects Flyway 10.x. The auto-configuration in Spring Boot 3.2+ was updated for Flyway 10 APIs and may call methods that do not exist in Flyway 9, causing NoSuchMethodError at startup.

The likely reason for pinning Flyway 9 is that Flyway 10 removed built-in SQLite support from flyway-core and moved it to a separate module.

To fix this:
1. Remove the explicit flyway-core version override (or update to 10.x to match Spring Boot 3.4.5's managed version).
2. Add the Flyway SQLite database module dependency, e.g.: implementation 'org.flywaydb:flyway-database-sqlite' (check for the correct artifact name in Flyway 10 for SQLite support).
3. Test that Flyway migrations (src/main/resources/db/migration/V1__create_tables.sql) run correctly against the sqlite datasource.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[devin-ai-integration]

Investigated this — Flyway 9.22.3 works correctly with Spring Boot 3.4.5 in this project. Verified by:

1. All 68 tests pass — these are integration tests that boot the full Spring context with Flyway auto-configuration enabled
2. ./gradlew bootRun starts cleanly — Flyway runs migrations successfully:

   o.f.c.internal.license.VersionPrinter    : Flyway Community Edition 9.22.3
   org.flywaydb.core.FlywayExecutor         : Database: jdbc:sqlite:dev.db (SQLite 3.47)
   o.f.core.internal.command.DbValidate     : Successfully validated 1 migration
   o.f.core.internal.command.DbMigrate      : Schema "main" is up to date. No migration necessary.
   

3. API responds correctly — GET /tags returns {"tags":[]}

Spring Boot 3.4.5's FlywayAutoConfiguration gracefully handles Flyway 9.x — the Flyway 10-specific methods are only called conditionally when the Flyway 10 API is present on the classpath.

The pin to 9.22.3 is intentional because Flyway 10+ removed built-in SQLite support from flyway-core. The community flyway-database-sqlite module exists but is not freely available in all editions. Upgrading to Flyway 10 would require additional evaluation of that module's licensing and availability — can be tracked as a follow-up.