no default JsonSchemaValidatorSupplier or default McpJsonMapper in mcp-json project

[scottslewis]

As per bug #562 I'm also getting these exceptions when running the latest 0.14.0 in repo (not deployed yet).

java.lang.IllegalStateException: No default JsonSchemaValidatorSupplier implementation found
at io.modelcontextprotocol.json.schema.JsonSchemaInternal.lambda$createDefaultValidator$2(JsonSchemaInternal.java:66)
at java.base/java.util.Optional.orElseThrow(Optional.java:403)
at io.modelcontextprotocol.json.schema.JsonSchemaInternal.createDefaultValidator(JsonSchemaInternal.java:61)
at io.modelcontextprotocol.json.schema.JsonSchemaInternal.getDefaultValidator(JsonSchemaInternal.java:30)
at io.modelcontextprotocol.json.schema.JsonSchemaValidator.getDefault(JsonSchemaValidator.java:61)
at io.modelcontextprotocol.server.McpServer$SingleSessionAsyncSpecification.build(McpServer.java:232)
at ...

and

java.lang.IllegalStateException: No default McpJsonMapper implementation found
at io.modelcontextprotocol.json.McpJsonInternal.lambda$createDefaultMapper$2(McpJsonInternal.java:67)
at java.base/java.util.Optional.orElseThrow(Optional.java:403)
at io.modelcontextprotocol.json.McpJsonInternal.createDefaultMapper(McpJsonInternal.java:62)
at io.modelcontextprotocol.json.McpJsonInternal.getDefaultMapper(McpJsonInternal.java:30)
at io.modelcontextprotocol.json.McpJsonMapper.getDefault(McpJsonMapper.java:97)
at io.modelcontextprotocol.server.McpServer$SingleSessionSyncSpecification.build(McpServer.java:818)
at ...

This problem does not appear to me to be an OSGi problem as when I look in the mcp-json project there does not appear to be any META-INF/services/* files. I can see that the ServiceLoader is used in io.modelcontextprotocol.json.schema.JsonSchemaInternal line 41, and in io.modelcontextprotocol.json.McpJsonInternal line 45, so I suspect that the META-INF/services/* files in mcp-json were accidently not checked in.

[garpinc]

I have service loader working in my osgi project for some bundles if I use require bundle. But I think because of shared packages between jars that might be causing issues for this.

[graemerocher]

this is by design you have to add an implementation like https://github.com/modelcontextprotocol/java-sdk/tree/main/mcp-json-jackson2

[scottslewis]

this is by design you have to add an implementation like https://github.com/modelcontextprotocol/java-sdk/tree/main/mcp-json-jackson2

This design doesn't work for osgi runtimes. Issue #541.

I imagine fragments could be used.

[jwflicker]

not sure if relevant, but I was getting similar errors where a downstream test plugin was re-using the mcp packages that i exported from an upstream plugin, but was able to address by adding a services folder to my downstream plugin ...

following the pattern here:
https://github.com/modelcontextprotocol/java-sdk/tree/main/mcp-json-jackson2/src/main/resources/META-INF/services

[scottslewis]

not sure if relevant, but I was getting similar errors where a downstream test plugin was re-using the mcp packages that i exported from an upstream plugin, but was able to address by adding a services folder to my downstream plugin ...

Yes. Your strategy works because your code calls the mcp-java-sdk's default json mapper creation code...which calls ServlceLoader.load here) to load the supplier instance (and call the supplier's 'get' method to get the McpJsonMapper instance).

The ServlceLoader.load method uses the ThreadContext Classloader to look for these files in META-INF/services. It can find them when you copy them into your application code, because the thread context classloader 'knows' about your files and not about the original ones.

[chemicL]

I believe this has been resolved with the recent changes. @scottslewis please correct me if I'm wrong and we can reopen.