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
5.1 KiB
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:
-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:
-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.