feat: Support multiple OpenAPI specs per server#97
Merged
Conversation
The constructor now takes List<SpecBinding> instead of Spec; the Builder synthesises a single-element list so the public API is unchanged. HandlerConfig drops the handlers and securityValidators fields (moved to SpecBinding). The not-found catch-all context is registered only when no binding has a root base path.
Introduces two addSpec() overloads on OpenApiServer.Builder: one accepting a Spec, handler map, and security-validator map, and one convenience form with no validators. The build() method is rewritten to either consume the bindings list (addSpec path) or synthesise a single binding from the legacy spec()/handlers()/securityValidator() fields. Mixing the two forms throws IllegalStateException. Cross-binding duplicate-basePath detection added.
|
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
1 participant
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.
Summary
OpenApiServer.Builder.addSpec(spec, handlers, validators)so one server can host multiple OpenAPI specs (e.g. v1/v2 side-by-side or public + admin in one process)basePathas an independent binding with its own handler/validator maps —operationIds and security-scheme names only need to be unique within a single spec.spec()/.handler()/.securityValidator()) is preserved; mixing it withaddSpec()in the same builder is rejected at build time/plus/api/...) are allowed and resolved by the JDKHttpServer's longest-prefix-matchDesign:
docs/superpowers/specs/2026-05-22-multiple-specs-design.mdImplementation plan:
docs/superpowers/plans/2026-05-22-multiple-specs.mdTest plan
mvn test— 470 unit tests pass (5 new inMultiSpecServerTestcovering namespacing, duplicate basePath, per-binding security wiring, legacy+addSpec rejection)mvn verify— 67 integration tests pass (newMultiSpecServerITboots a realHttpServerwith two derived specs at/api/v1and/api/v2)Specinstances from the existingopenapi.jsonvia a newSpecFixtureshelperaddSpec()usage