asmhatre
baff043748
- naive @SchemaMapping resolver: 6 statements (5 books/5 authors), 21 statements (20 books/5 authors) - batched @BatchMapping resolver: flat 2 statements in both cases, via DataLoader + .distinct() - dangling authorId nulls the entire GraphQL response via non-null propagation, byte-identical under both resolver strategies - 6-test suite over real HTTP against a live embedded Tomcat instance, SQL captured via a JDK dynamic proxy (StatementLoggingDataSource, reused from sdjpa4-demo) - docs/05: two Boot 4.1 packaging changes hit along the way (DataSourceAutoConfiguration's new package, Jackson 3 by default) - root README: add row for graphql-dataloader; fix openapi-versioning's placeholder link now that post 7477 is live
101 lines
5.1 KiB
Markdown
101 lines
5.1 KiB
Markdown
# 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.
|