Release package 1.7.0 fails at runtime with `NoSuchMethodError` (ResolverFully) — missing transitive Swagger JARs?

[cmorasca]

Summary

I installed the 1.7.0 release package on several API Gateway / API Manager builds and could not get the validator to work on any of them. Every request that hits the OpenAPIValidator filter fails during initialization with a java.lang.NoSuchMethodError for io.swagger.v3.parser.util.ResolverFully.<init>(io.swagger.v3.parser.core.models.ParseOptions).

After digging into the classpath and the release contents, I believe the release zip/tar only ships a subset of the Swagger parser dependency tree — specifically, swagger-parser-v3 (and several other transitive libraries) appear to be missing from ext/lib. At runtime the gateway seems to fall back to an older swagger-parser-v3 already on the API Gateway classpath, which does not have the constructor that swagger-parser-v2-converter:2.1.34 expects.

I'm opening this issue to ask: is this a packaging bug in the 1.7.0 release, or am I missing something in the installation steps? I followed the README (download release → install under ext/lib → restart gateway) and did not find any extra dependency step documented.

---

Environment

Item	Value
Validator release tested	openapi-validator-1.7.0 (official release package from GitHub)
API Gateway / API Manager versions tested	7.7.20250228, 7.7.20250530, 7.7.20260530
Specs tested	Swagger 2.0 Petstore (imported into API Manager) and an OpenAPI spec I built based on the DummyJSON Users API
swagger-request-validator-core (bundled)	2.46.0
swagger-parser (io.swagger.parser.v3, bundled)	2.1.34

Same symptom on all three gateway versions with both test APIs — I did not get a working deployment with the stock 1.7.0 package on any of them.

---

Symptom

The policy flow itself works fine (route matched, auth OK, parameters built). The failure happens inside the Scripting Language filter when calling OpenAPIValidator.getInstance(...):

ERROR  java exception:
java.lang.NoSuchMethodError: 'void io.swagger.v3.parser.util.ResolverFully.<init>(io.swagger.v3.parser.core.models.ParseOptions)'
    at io.swagger.v3.parser.converter.SwaggerConverter.readResult(SwaggerConverter.java:107)
    at io.swagger.v3.parser.converter.SwaggerConverter.readContents(SwaggerConverter.java:99)
    at io.swagger.parser.OpenAPIParser.readContents(OpenAPIParser.java:29)
    at com.atlassian.oai.validator.util.OpenApiLoader.readSwaggerParserResult(OpenApiLoader.java:72)
    at com.atlassian.oai.validator.util.OpenApiLoader.loadApi(OpenApiLoader.java:48)
    at com.atlassian.oai.validator.OpenApiInteractionValidator$Builder.build(OpenApiInteractionValidator.java:672)
    at com.axway.apim.openapi.validator.OpenAPIValidator.<init>(OpenAPIValidator.java:103)
    at com.axway.apim.openapi.validator.OpenAPIValidator.getInstance(OpenAPIValidator.java:72)
    ...

The gateway then returns HTTP 500 for the request.

---

What I investigated

NoSuchMethodError usually means a classpath / version mismatch, not bad user code or a bad API spec. Here is what I found:

1. The bundled swagger-parser-v2-converter:2.1.34 (SwaggerConverter) calls new ResolverFully(ParseOptions).
2. That constructor exists in swagger-parser 2.1.x. Older versions only expose ResolverFully() / ResolverFully(boolean).
3. The class ResolverFully lives in io.swagger.parser.v3:swagger-parser-v3, which was not in my ext/lib after installing the 1.7.0 release as-is.
4. Because it was missing, the JVM loaded ResolverFully from the gateway's own (older) Swagger libraries → constructor not found → NoSuchMethodError.

Since one of my test APIs is Swagger 2.0 (Petstore), the code path goes through Swagger 2.0 → OpenAPI 3.0 conversion (SwaggerConverter), which pulls in both the v3 parser family and the legacy io.swagger:* (1.x) artifacts. The other test API is OpenAPI 3.x (DummyJSON Users). Both hit the same class of classpath problems with the stock 1.7.0 package.

What ext/lib contained after installing release 1.7.0 (broken for me)

openapi-validator-1.7.0.jar
swagger-parser-2.1.34.jar                  <- very small (~3 KB), looks like a facade/aggregator only
swagger-parser-v2-converter-2.1.34.jar
swagger-request-validator-core-2.46.0.jar

That is only 4 JARs plus the validator itself. When I compared against the Maven dependency tree of swagger-request-validator-core:2.46.0, many transitive artifacts were absent from the release package.

Dependency tree I expected (from Maven)

com.atlassian.oai:swagger-request-validator-core:2.46.0
└─ io.swagger.parser.v3:swagger-parser:2.1.34
   ├─ io.swagger.parser.v3:swagger-parser-v2-converter:2.1.34
   │  ├─ io.swagger:swagger-core:1.6.16
   │  │  └─ io.swagger:swagger-models:1.6.16
   │  │     └─ io.swagger:swagger-annotations:1.6.16
   │  ├─ io.swagger:swagger-parser:1.0.75
   │  │  └─ io.swagger:swagger-parser-safe-url-resolver:1.0.75
   │  ├─ io.swagger:swagger-compat-spec-parser:1.0.75
   │  ├─ io.swagger.core.v3:swagger-models:2.2.37
   │  └─ io.swagger.parser.v3:swagger-parser-core:2.1.34
   ├─ io.swagger.parser.v3:swagger-parser-v3:2.1.34     <- contains ResolverFully (MISSING in release)
   │  ├─ io.swagger.core.v3:swagger-core:2.2.37
   │  │  └─ io.swagger.core.v3:swagger-annotations:2.2.37
   │  └─ io.swagger.parser.v3:swagger-parser-safe-url-resolver:2.1.34
   └─ org.yaml:snakeyaml:2.4

I looked at src/assembly/dist.xml in the repo and noticed the <includes> filter only whitelists a couple of io.swagger.parser.v3 artifacts explicitly. My guess is the assembly plugin silently drops the rest of the transitive tree — but I might be wrong about how the release is supposed to be built or consumed.

---

What I tried / what finally worked for me

Attempt 1 — stock 1.7.0 release (failed)

• Downloaded the 1.7.0 release zip from GitHub.
• Copied everything into ext/lib as documented in the README.
• Restarted the API Gateway.
• Result: NoSuchMethodError on every validation attempt (all three gateway versions listed above).

Attempt 2 — manually add missing JARs to stock 1.7.0 (failed — API Manager regressions)

Before rebuilding from source, I tried manually copying the missing Swagger JARs into ext/lib on top of the stock 1.7.0 release (starting with swagger-parser-v3-2.1.34.jar, then adding more from the Maven tree). This did not work reliably and caused API Manager to behave strangely:

• API import from file stopped working — I could no longer import APIs from a local spec file.
• Fetching the API contract from API Manager failed — the validator could not download the frontend spec.

With the DummyJSON Users API, the validator fails before it even gets to parse the payload — API Manager returns HTTP 500 when the validator tries to fetch the spec:

ERROR  OpenAPIValidator: Error getting API-Specification from API-Manager. Received Status-Code: 500, Response: '{"errors":[{"code":500,"message":"Failed to download API"}]}'
ERROR  OpenAPIValidator: Error creating OpenAPIValidator for given API-ID: db4b81e3-0388-474e-8567-73cd92443ba9:
java.lang.IllegalArgumentException: Error getting API-Specification from API-Manager.
    at com.axway.apim.openapi.validator.APIManagerSchemaProvider.getFrontendAPISpec(APIManagerSchemaProvider.java:50)
    ...

With Petstore (Swagger 2.0), the spec is downloaded successfully (I can see the full JSON in the trace log), but validation still fails — this time with a different NoSuchMethodError, which suggests a mixed/partial classpath rather than a clean fix:

java.lang.NoSuchMethodError: 'boolean io.swagger.v3.parser.core.models.ParseOptions.isExplicitStyleAndExplode()'
    at io.swagger.v3.parser.util.OpenAPIDeserializer.deserialize(OpenAPIDeserializer.java:309)
    at io.swagger.v3.parser.OpenAPIV3Parser.parseJsonNode(OpenAPIV3Parser.java:147)
    at io.swagger.v3.parser.OpenAPIV3Parser.readContents(OpenAPIV3Parser.java:178)
    at io.swagger.parser.OpenAPIParser.readContents(OpenAPIParser.java:29)
    at com.atlassian.oai.validator.util.OpenApiLoader.readSwaggerParserResult(OpenApiLoader.java:72)
    at com.axway.apim.openapi.validator.OpenAPIValidator.<init>(OpenAPIValidator.java:103)
    ...

So adding JARs by hand on top of 1.7.0 seems to make things worse: some classes come from the new JARs, others still from the gateway's own Swagger libraries → more NoSuchMethodErrors and collateral damage to API Manager features that also depend on Swagger.

Attempt 3 — fix the assembly locally and rebuild (worked)

I cloned the repo and changed src/assembly/dist.xml so the release bundles the full Swagger tree instead of a hand-picked subset:

Before (what I believe 1.7.0 shipped with):

<includes>
    <include>io.swagger.parser.v3:swagger-parser-v2-converter</include>
    <include>io.swagger.parser.v3:swagger-parser</include>
    <include>com.atlassian.oai:swagger-request-validator-core</include>
    <include>com.github.axway-api-management-plus.openapi-validator:*</include>
</includes>

After (what worked for me locally):

<includes>
    <include>io.swagger.parser.v3:*</include>
    <include>io.swagger.core.v3:*</include>
    <include>io.swagger:*</include>
    <include>org.yaml:snakeyaml</include>
    <include>com.atlassian.oai:swagger-request-validator-core</include>
    <include>com.github.axway-api-management-plus.openapi-validator:*</include>
</includes>

Then:

mvn -DskipTests clean package

The generated ext/lib now contained the full set, including swagger-parser-v3-2.1.34.jar. After backing up ext/lib, deploying that build, ensuring there was only one openapi-validator-*.jar, and restarting the gateway, the NoSuchMethodError disappeared. Both test APIs (Petstore and DummyJSON Users) validated correctly instead of returning HTTP 500.

---

Questions for the maintainers

1. Is the 1.7.0 release package supposed to work out of the box with only the 4–5 JARs it currently ships, relying on Swagger libraries already present on the gateway classpath? If so, is there a minimum gateway version or additional install step I missed?

2. Or is the assembly descriptor intentionally incomplete, and the fix is to broaden the <includes> in dist.xml for future releases (as I did locally)?

3. Side-effect concern (now confirmed in my testing): adding Swagger JARs to ext/lib puts them on the global gateway classpath, where they can shadow the gateway's own Swagger libraries (API Manager, API Catalog, spec import, contract download, etc.). When I tried the partial manual-JAR workaround, API Manager import and spec download broke. Even with the full rebuilt package, I want to understand whether this is an accepted trade-off long-term, or if a shaded/relocated uber-jar approach would be safer so the validator cannot interfere with the gateway runtime.

---

What does not work (please avoid)

Manually copying missing Swagger JARs on top of the stock 1.7.0 release is not a viable workaround in my experience. It produces inconsistent classpath loading (different NoSuchMethodErrors depending on which classes get shadowed) and breaks unrelated API Manager functionality such as importing APIs from file and downloading the frontend contract. The only approach that worked for me was deploying the complete dependency set from a locally rebuilt package.

---

What would help me (and probably others)

• Confirmation whether 1.7.0 packaging is known to be incomplete, or if my install was wrong.
• If it is a packaging issue: a patched release (or updated assembly) that ships the complete transitive Swagger dependency set.
• Any guidance on whether bundling Swagger JARs in ext/lib is safe long-term on production gateways, or if shading is on the roadmap.

Happy to provide more logs, the exact contents of my ext/lib, or test a fixed release package on my environments if that helps.