JsonSchemaValidator fails to load schema in OSGi environments

Bug description
When I try to run the MCP Server with version 2.0.0-M3 it does not start, because it can't find the schema.

 SchemaRegistry :775 |  Failed to load json schema from https://json-schema.org/draft/2020-12/schema
java.io.FileNotFoundException: classpath:draft/2020-12/schema
        at com.networknt.schema.resource.ClasspathResourceLoader.lambda$getResource$0(ClasspathResourceLoader.java:75)
        at com.networknt.schema.SchemaRegistry.getMappedSchema(SchemaRegistry.java:749)
        at com.networknt.schema.SchemaRegistry.loadSchema(SchemaRegistry.java:734)
        at com.networknt.schema.SchemaRegistry.getSchema(SchemaRegistry.java:649)
        at io.modelcontextprotocol.json.schema.jackson3.DefaultJsonSchemaValidator.<init>(DefaultJsonSchemaValidator.java:54)

Environment
SDK: 2.0.0-M3

Steps to reproduce

Try to start the server

Expected behavior

Server should start normally

@tim-schneider-elo

@tim-schneider-elo , could you please elaborate on this issue and explain how to reproduce it?

I had a running project with an MCP Server running as an OSGI-Bundle

I updated the dependency to use version 2.0.0-M3, now it fails to start the plugin, because the server throws this error message I mentioned. I changed nothing else

My code/project works with version 2.0.0-M1, 2.0.0-M2, but not with 2.0.0-M3 and 2.0.0-RC1.

@tim-schneider-elo

@tim-schneider-elo thanks for explaining. I changed the name to highlight that this is a problem for OSGi. I am not certain if this is a java-sdk specific problem or com.networknt.schema issue. This seems to be caused by loading the 2020-12 schema definition required in order to validate by default the specific dialect as the spec requires (#700).

Also, isn't this fixed by the way by #948? If so, we can close as duplicate. Please confirm with 2.0.0 which we released today.

I did try it with the release 2.0.0 but it still fails.

We don't use the Import/Export-Package functionality properly, so I don't think it has to do with #948
We include everything in the Bundle-Classpath

@tim-schneider-elo

This seems to be classloader issue.

Providing a reproducing project would help us debug. My coding agent suggests using the lib's ClassLoader itself:

this.schemaFactory = SchemaRegistry.withDefaultDialect(Dialects.getDraft202012(),
    builder -> builder.resourceLoaders(rl ->
        rl.add(new ClasspathResourceLoader(ClasspathResourceLoader.class::getClassLoader))
    )
);

It does not break my build locally, but I don't know if it would fix your specific issue.

edit: tagging @tim-schneider-elo

@Kehrlann

@Kehrlann I independently ran into this issue and found the root cause.

I believe the proper fix would be upstream, as described in networknt/json-schema-validator#1264. I proposed a fix in networknt/json-schema-validator#1265 (master, 3.x) and networknt/json-schema-validator#1266 (2.x).

Note that configuring the custom resource loader as you suggested unfortunately does not work: SchemaLoader.getSchemaResource() consults the static classpath loader before any configured loaders, so classpath: IRIs never reach them.

IMHO applying the upstream fix and bumping json-schema-validator-jackson2.version / json-schema-validator-jackson3.version in this project would be the right approach.

@tim-schneider-elo

@tim-schneider-elo until the fix ships, two possible workarounds we considered in the project I'm working on, in case they're useful to you:

Quick: swap the TCCL to the validator bundle's class loader around construction: (This only works if the validator is actually constructed inside the wrapped call stack.)

ClassLoader tccl = Thread.currentThread().getContextClassLoader();
Thread.currentThread().setContextClassLoader(SchemaRegistry.class.getClassLoader());
try {
    validator = new DefaultJsonSchemaValidator();
} finally {
    Thread.currentThread().setContextClassLoader(tccl);
}

More robust: create a drop-in JsonSchemaValidator implementation, same as DefaultJsonSchemaValidator except its registry overrides classpath resolution to use the library's own class loader. This avoids the thread-state mutation (arguably nicer):

this.schemaFactory = SchemaRegistry.withDefaultDialect(Dialects.getDraft202012(), builder ->
    builder.schemaLoader(new SchemaLoader(Collections.emptyList(), Collections.emptyList()) {
        @Override
        protected InputStreamSource getClasspathResource(AbsoluteIri iri) {
            return new ClasspathResourceLoader(SchemaLoader.class::getClassLoader).getResource(iri);
        }
    }));

The upstream fix is released: json-schema-validator 2.0.4 / 3.0.6 restore the class-loader fallback (networknt/json-schema-validator#1264). #1058 bumps the SDK to those versions — verified against an embedded-Felix reproducer for both Jackson modules.

@joaodinissf

@joaodinissf thanks for the upstream fix, that's very useful!

Bump json-schema-validator to 2.0.4 / 3.0.6 (modelcontextprotocol#1058)

Thanks, the mentioned workaround works for me. Looking forward to 2.0.1 release 👍

Navigation Menu

Repository navigation

JsonSchemaValidator fails to load schema in OSGi environments #992

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

JsonSchemaValidator fails to load schema in OSGi environments #992

Description

Activity

tzolov commented on Jun 10, 2026

tim-schneider-elo commented on Jun 11, 2026

chemicL commented on Jun 11, 2026

tim-schneider-elo commented on Jun 15, 2026

Kehrlann commented on Jun 24, 2026

joaodinissf commented on Jul 7, 2026

joaodinissf commented on Jul 7, 2026

joaodinissf commented on Jul 8, 2026

Kehrlann commented on Jul 8, 2026

tim-schneider-elo commented on Jul 9, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions