# Two Boot 4.1 packaging changes this module ran into directly

Neither of these is about GraphQL or DataLoader batching — they're genuine build-time surprises
from targeting Spring Boot 4.1.1 that are worth recording here because they cost real debugging
time and because searching for the old, Boot-3-era package names will still turn up plenty of
now-stale documentation and Stack Overflow answers.

## `DataSourceAutoConfiguration` moved packages

The very first `mvn clean package` on this module failed with:

```
[ERROR] package org.springframework.boot.autoconfigure.jdbc does not exist
[ERROR] cannot find symbol
  symbol: class DataSourceAutoConfiguration
```

`@SpringBootApplication(exclude = DataSourceAutoConfiguration.class)` is used here for the same
reason it's used in the sdjpa4-demo companion project: to stop Boot's own auto-configuration from
building a `DataSource` from `application.yml` properties, so the custom `@Bean DataSource` method
wrapping H2 in `StatementLoggingDataSource` is the only one that ever runs. In Spring Boot 3, that
class lived at `org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration`, inside
the single, large `spring-boot-autoconfigure` artifact.

As of Boot 4.1.1, `spring-boot-autoconfigure` only contains the generic auto-configuration
*infrastructure* — `AutoConfigurationImportSelector`, `AutoConfigurations`, and similar — confirmed
directly by listing the jar:

```
$ unzip -l spring-boot-autoconfigure-4.1.1.jar | grep -i jdbc
(no output)
```

The actual per-feature auto-configuration classes now live in their own per-feature artifacts, in
new packages. `DataSourceAutoConfiguration` specifically is in `spring-boot-jdbc-4.1.1.jar`, at
`org.springframework.boot.jdbc.autoconfigure.DataSourceAutoConfiguration` — the `jdbc` and
`autoconfigure` segments swapped relative to the old package name. The fix was a one-line import
change:

```diff
-import org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration;
+import org.springframework.boot.jdbc.autoconfigure.DataSourceAutoConfiguration;
```

The sdjpa4-demo companion project (for the Spring Data JDBC vs. JPA article) already used the
correct new package — this module's `GraphqlDataloaderApplication.java` was written from habit
before that was double-checked here directly.

## Jackson 3 by default

Writing the HTTP-level test assertions for docs/02–docs/04 initially used
`com.fasterxml.jackson.databind.{ObjectMapper,JsonNode}`, which failed to compile:

```
[ERROR] package com.fasterxml.jackson.databind does not exist
```

`mvn dependency:tree` on this module shows why:

```
+- org.springframework.boot:spring-boot-starter-jackson:jar:4.1.1:compile
|  \- org.springframework.boot:spring-boot-jackson:jar:4.1.1:compile
|     \- tools.jackson.core:jackson-databind:jar:3.1.5:compile
|        +- com.fasterxml.jackson.core:jackson-annotations:jar:2.21:compile
|        \- tools.jackson.core:jackson-core:jar:3.1.5:compile
```

Spring Boot 4.1's default Jackson integration is Jackson 3, whose `jackson-core` and
`jackson-databind` modules moved to the `tools.jackson.core` Maven group and the
`tools.jackson.databind` / `tools.jackson.core` Java packages — a deliberate break from the
`com.fasterxml.jackson.*` namespace Jackson 2 used. `jackson-annotations` is the one piece that
stayed on the old `com.fasterxml.jackson.core` group (at 2.21), since annotations are largely
shared/compatible across the 2.x/3.x line. The fix in this module's test classes was the same shape
as the `DataSourceAutoConfiguration` one — swap the import, not the code:

```diff
-import com.fasterxml.jackson.databind.JsonNode;
-import com.fasterxml.jackson.databind.ObjectMapper;
+import tools.jackson.databind.JsonNode;
+import tools.jackson.databind.ObjectMapper;
```

`ObjectMapper.writeValueAsString(...)` and `.readTree(...)` behave identically once the import is
fixed — this module didn't need any further changes to its JSON-handling code. Projects still on
`spring-boot-starter-web`/`spring-boot-starter-json` from a Boot 3.x background, or projects that
pull in `com.fasterxml.jackson.core:jackson-databind` directly rather than through a Boot starter,
should expect to hit this the first time they add any code that touches `ObjectMapper` or
`JsonNode` directly after upgrading to Boot 4.1.

## What was, and wasn't, independently verified here

Every SQL statement count and every GraphQL error message in docs/02–docs/04 came from this
module's own test runs against real H2 and a real embedded Tomcat instance — nothing in those three
chapters is asserted from documentation or memory. The two packaging changes above were confirmed
directly by inspecting the actual `.jar` contents downloaded into the local Maven repository for
this build (`unzip -l`), not by trusting a changelog summary. What was *not* independently
re-derived from first principles here is the general architectural claim that Spring Boot 4
modularized auto-configuration into per-feature artifacts — that's stated as context, based on what
this module's own dependency tree and jar contents show, not as an exhaustively researched survey
of every module that moved.