fix(spring): [Data Collection 18] Bind key-value policies

[adinauer]

PR Stack (Data Collection)

• feat(core): Data Collection #5759
• feat(core): [Data Collection 1] Add configuration types #5760
• feat(core): [Data Collection 2] Expose SentryOptions API #5761
• feat(core): [Data Collection 3] Add policy resolver #5799
• feat(graphql): [Data Collection 4] Apply GraphQL policies #5800
• feat(database): [Data Collection 5] Apply query policy #5801
• feat(spring): [Data Collection 6] Apply incoming request body policy #5802
• feat(apollo): [Data Collection 7] Apply incoming response body policy #5803
• feat(apollo): [Data Collection 8] Apply outgoing request body policy #5804
• feat(graphql): [Data Collection 9] Apply outgoing response body policy #5805
• feat(http): [Data Collection 10] Apply request header policy #5806
• feat(http): [Data Collection 11] Apply response header policy #5807
• feat(http): [Data Collection 12] Apply query parameter policy #5810
• feat(http): [Data Collection 13] Apply cookie collection policy #5811
• feat(user): [Data Collection 14] Apply user information policy #5812
• fix(android): [Data Collection 15] Scope device info cache to SDK options #5831
• test(replay): [Data Collection 16] Keep Replay independent #5832
• fix(spring): [Data Collection 18] Bind key-value policies #5834
• fix(android): [Data Collection 19] Preserve installation ID #5937
• fix(ktor): [Data Collection 20] Exclude query parameters from span descriptions #5983
• feat(core): [Data Collection 21] Add external configuration #6036
• feat(android): [Data Collection 22] Add manifest configuration #6038
• fix(core): [Data Collection 23] Support WebSocket URL parsing #6064
• fix(core): [Data Collection 24] Narrow utility exception handling #6065

---

📜 Description

Make KeyValueCollectionBehavior JavaBean-bindable so Spring Boot can configure Data Collection policies for cookies, URL query parameters, and request/response headers.

Add a public no-argument constructor with the default deny-list behavior and setters for mode and terms. The existing off, denyList, and allowList factories remain available, and terms continue to be defensively copied into an immutable list.

💡 Motivation and Context

Spring Boot could bind scalar Data Collection fields but silently ignored nested key-value policies because KeyValueCollectionBehavior only exposed private construction and immutable fields. A scalar property could therefore make the namespace explicit while the requested cookie, query, or header restriction was not applied.

Refs #5666

💚 How did you test it?

• ./gradlew :sentry:test --tests io.sentry.KeyValueCollectionBehaviorTest :sentry-spring-boot:test --tests 'io.sentry.spring.boot.SentryAutoConfigurationTest.data collection key value properties are applied to SentryOptions' :sentry-spring-boot-jakarta:test --tests 'io.sentry.spring.boot.jakarta.SentryAutoConfigurationTest.data collection key value properties are applied to SentryOptions' :sentry-spring-boot-4:test --tests 'io.sentry.spring.boot4.SentryAutoConfigurationTest.data collection key value properties are applied to SentryOptions'
• ./gradlew spotlessApply apiDump
• git diff --check

📝 Checklist

• I added GH Issue ID & Linear ID
• I added tests to verify the changes.
• No new PII added or SDK only sends newly added PII if sendDefaultPII is enabled.
• I updated the docs if needed.
• I updated the wizard if needed.
• Review from the native team if needed.
• No breaking change or entry added to the changelog.
• No breaking change for hybrid SDKs or communicated to hybrid SDKs.
• Public API changes reviewed by another Mobile SDK team member or implemented according to the develop docs spec.

🔮 Next steps

Add the remaining external and Android manifest Data Collection configuration paths.

#skip-changelog

⚠️ Merge this PR using a merge commit (not squash). Only the collection branch is squash-merged into main.

[sentry]

📲 Install Builds

Android

🔗 App Name	App ID	Version	Configuration
SDK Size	io.sentry.tests.size	8.55.0 (1)	release

⚙️ sentry-android Build Distribution Settings

[github-actions]

Performance metrics 🚀

	Plain	With Sentry	Diff
Startup time	406.17 ms	481.60 ms	75.44 ms
Size	0 B	0 B	0 B

Baseline results on branch: feat/data-collection-session-replay-network-options

Startup times

Revision	Plain	With Sentry	Diff
369f0bb	316.96 ms	356.40 ms	39.44 ms
543680b	325.17 ms	471.02 ms	145.85 ms
1d4f70d	365.04 ms	441.86 ms	76.81 ms

App size

Revision	Plain	With Sentry	Diff
369f0bb	0 B	0 B	0 B
543680b	0 B	0 B	0 B
1d4f70d	0 B	0 B	0 B

Previous results on branch: fix/data-collection-spring-binding

Startup times

Revision	Plain	With Sentry	Diff
6f6d5e3	307.56 ms	352.77 ms	45.21 ms
62f0348	366.32 ms	435.63 ms	69.31 ms
a02f4d4	307.58 ms	353.86 ms	46.28 ms

App size

Revision	Plain	With Sentry	Diff
6f6d5e3	0 B	0 B	0 B
62f0348	0 B	0 B	0 B
a02f4d4	0 B	0 B	0 B

[github-actions]

Semver Impact of This PR

🟢 Patch (bug fixes)

📋 Changelog Preview

This is how your changes will appear in the changelog.
Entries from this PR are highlighted with a left border (blockquote style).

---

This PR will not appear in the changelog.

---

_{🤖 This preview updates automatically when you update the PR.}

[lbloder]

LGTM 👍

[runningcode]

Up until this PR, KeyValueCollectionBehavior was immutable. This is important because DataCollectionResolver holds two static final KeyValueCollectionBehaviors.
This means that users can modify the static singleton which is not a good idea.
I think we should rather keep this class immutable to prevent issues.

[adinauer]

Ah good catch!

Unfortunately this isn't easily possible for Spring Boot property binding. I will simply inline the static fields to call the factory methods directly.