Conversation
Confirms Jersey 4.0.x pins Jackson 3 provider support and jackson-annotations 3.x retains the com.fasterxml.jackson.annotation package, so D2 adopts Jackson 3 rather than shipping 4.0 on Jackson 2.
Boots a real @SpringBootApplication through each published starter (core, app, and the test-spring-boot re-export) so autoconfiguration repackaging in Spring Boot 4 is caught by discovery rather than by tests that assemble a context by hand via AutoConfigurations. Written and passing against 3.5.16 first, before the platform bump, so they can demonstrate they would have caught the failure (D5).
Moves spring-boot-dependencies to 4.0.0 and realigns the jersey-bom import to the Jersey line it pins. Drops the Netty and Tomcat CVE overrides (D3) since Spring Boot 4 brings Netty 4.2 / Tomcat 11, both of which already win conflict resolution against the old constraints, and their comments cite CVEs specific to the Tomcat 10 line. Also drops the jakarta.ws.rs-api and jakarta.validation-api pins, including the duplicate validation-api pin in the app starter, early enough that any Jakarta EE 11 incompatibility surfaces now rather than after the rest of the migration is done.
@ConditionalOnMissingBean/@ConditionalOnProperty/@ConditionalOnBean and the AutoConfiguration.imports path are unchanged in Spring Boot 4, so the core and app starters' autoconfiguration classes need no import changes; the section 2 smoke tests are what confirm discovery still works. What does move: health SPI relocates to the new spring-boot-health module (AbstractHealthIndicator/Health/Status -> ...boot.health.contributor), HttpHeaders.asHttpHeaders() exposes headerSet() instead of entrySet() in Spring Framework 7, and org.springframework.boot.test.mock.mockito.SpyBean is removed in favour of MockitoSpyBean.
Jersey 4.0's Apache connector moved from jersey-apache-connector (HttpClient 4, org.apache.http.*) to jersey-apache5-connector (HttpClient 5, org.apache.hc.*): ApacheConnectorProvider / ApacheClientProperties and the Registry-based SSL socket factory setup are replaced by their Apache5 equivalents, and ApiClientJersey2's NoHttpResponseException / ConnectTimeoutException imports move to org.apache.hc.core5 / org.apache.hc.client5. jakarta.ws.rs itself is untouched by this move. The jakarta.validation and jakarta.servlet.http usages, and jakarta.annotation.PostConstruct, needed no changes under Jakarta EE 11.
Adopts Jackson 3 per D2: a Jackson 3 JSON provider exists for the Jersey 4.0.x line Spring Boot 4 pins (tools.jackson.jakarta:jackson-jakarta-rs-json-provider), so the BOM moves from jackson-bom 2.18.8 to tools.jackson:jackson-bom, and the 22 hand-written com.fasterxml.jackson.databind/.core usages across symphony-bdk-config, symphony-bdk-core, symphony-bdk-http-jersey2, the Spring starters, and symphony-bdk-cli move to tools.jackson.*, along with their 5 test-side counterparts. jjwt-jackson is dropped in favour of a hand-rolled jjwt Serializer backed by the shared mapper, so only one Jackson databind implementation ever resolves on the classpath — enforced by a new verifySingleJacksonDatabind Gradle task wired into check. jackson-databind-nullable moves to 0.2.11 for its Jackson 3 backend, and JSON.java / RFC3339DateFormat.java are rewritten against the Jackson 3 JsonMapper builder API and java.time respectively, since Jackson 3 drops ISO8601DateFormat/ISO8601Utils. BdkConfigParser's 3 public JsonNode-returning signatures change package as a result — a breaking API change for direct callers, to be called out in the migration guide.
Adds the multi-store-aware /opsx:sync command and skill, updates the existing apply/archive/explore/propose commands and skills for store selection, and mirrors all opsx commands/skills for the Gemini CLI.
|
SNAPSHOT published: |
…nge (#891) Pulls in Spring Boot 4.0.7, Netty 4.2.16, httpclient5/httpcore5, Tomcat embed, and opennlp-tools patch versions ahead of what their parent BOMs pin, to close several CVEs before the change is finalized. Archives the completed OpenSpec change and syncs its deltas into the main specs.
The release workflow rejected 'v4.0.0-alpha.1' because the tag regex only matched vMAJOR.MINOR.PATCH. Allow optional SemVer pre-release and build-metadata suffixes so alpha/beta/rc tags can be released. Also accept the 'next' branch as a valid release source for 4.x, since 4.x is developed on 'next' until GA merges it into 'main'.
… transport (#894) * Propose OpenSpec change: JDK HttpClient-based ApiClient transport (#893) * Propose OpenSpec change: JDK HttpClient-based ApiClient transport Adds a third symphony-bdk-http implementation on top of java.net.http.HttpClient, giving consumers a zero-third-party-dependency alternative to jersey2/webclient. * Deprecate jersey2's default status in favor of symphony-bdk-http-jdk (D12) symphony-bdk-http-jersey2 carries the largest dependency/CVE surface for a filter-chain benefit nothing in the codebase uses. Make the new jdk module the documented default for symphony-bdk-core and mark jersey2's public classes @API(DEPRECATED) as a soft, non-removing signal — no functional change, no forced migration. * Add symphony-bdk-http-jdk module, a java.net.http.HttpClient-based ApiClient Implements the OpenSpec change jdk-httpclient-transport: a third ApiClient implementation with zero third-party HTTP dependencies, becoming the new documented default for symphony-bdk-core. symphony-bdk-http-jersey is deprecated (soft, non-removing @API status change) in that role but keeps shipping unchanged. * Address PR review nits on JDK HttpClient transport - Document ClassCastException risk in addFilter due to generics erasure - Wrap InvalidPathException from file.toPath() in ApiException for multipart uploads - Normalize slashes between basePath and path when building request URIs
…rage migration off jersey/webclient Clarify that as of BDK 4.x, symphony-bdk-http-jdk is the recommended default for both Core and Spring, and that symphony-bdk-http-jersey / symphony-bdk-http-webclient consumers should plan to migrate.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
BDK 3.x is built on Spring Boot 3.5, whose OSS support window has closed. Spring Boot 4 / Spring Framework 7 is the supported line, and this is the framework half of the BDK 4.x major.
What changes
Breaking changes (expected in a major):
Also in this branch
Test plan