SchemaLoader downloads external resources

[bannmann]

My application includes a local copy of the JSON schema metaschema, which looks like this:

{
    "id": "http://json-schema.org/draft-04/schema#",
    "$schema": "http://json-schema.org/draft-04/schema#",

Now when SchemaLoader is instructed to load this schema (from a local file), it attempts to fetch the resource given by the URL in the id property.

In a certain installation, my application is supposed to work offline, so this HTTP request is intercepted by the firewall, leading to an exception.

When I remove the "id" property, SchemaLoader does not attempt to fetch that resource.

I believe that this behavior is wrong, as per the following text in the JSON Schema spec (emphasis mine):

http://json-schema.org/latest/json-schema-core.html#rfc.section.8

The URI is not a network locator, only an identifier. A schema need not be downloadable from the address if it is a network-addressable URL, and implementations SHOULD NOT assume they should perform a network operation when they encounter a network-addressable URI.

http://json-schema.org/latest/json-schema-core.html#rfc.section.9.2.2

To differentiate schemas between each other in a vast ecosystem, schemas are identified by URI. As specified above, this does not necessarily mean anything is downloaded, but instead JSON Schema implementations SHOULD already understand the schemas they will be using, including the URIs that identify them.

Also, I wonder why the "id" property gets any special treatment: unless I'm mistaken, the spec assigns no specific meaning to this property, only to the "$id" property.

[erosb]

Hello @bannmann , thank you for submitting this issue.

You refer to sections of the latest version of the specification (which is unofficially called draft-6), while this library is the implementation of draft-4 (draft-4 core and draft-4 validation ). This is somewhat misleading, you can read a bit more on this wiki page.

Draft-6 was released in April. A new version of this library supporting draft-6 is on the way, i'm working on it, but there is no ETA.

Regarding offline behavior: the current implementation conforms to draft-4 , but if you want to customize networking, then I suggest creating a custom implementation of SchemaClient interface, and using it like this:

SchemaLoader loader = SchemaLoader.builder()
    .schemaJson(yourSchemaJson)
    .httpClient(yourSchemaClient).build();
Schema schema = loader.load().build();

Please note that this will still be used by the loader in the draft4 way.

[erosb]

Hello @bannmann , I released the new version yesterday with draft 6 support.

Links:

• Release notes
• Installation instructions

[bannmann]

Thanks for letting me know, @erosb!

We will try to move to the new version. It's a pity you decided to stop distributing releases via Maven Central, though, causing more work for us :-/ Out of curiosity, what were the reasons for this decision? It's an unusual thing to move away from the standard distribution platform in the Java world.

[erosb]

I'm sorry to hear it causes trouble for you. I decided to change from maven central to JitPack is that I left everit-org (the company) about 1,5 years ago, and I can't access their artifactory directly, I have to ask one of my ex-colleagues to do the release. After such a long time I would more prefer not bothering them with my hobby project, and anyway it would come with a more fluent release process (from my point) to distribute through JitPack.

If it causes complications for a lot of users then I may change it back.

[JakimLi]

@erosb, awesome job on this project, trying to use it, not being able to download it from maven central cause problem when this jar is a transitive dependency, in an enterprise environment, it needs the approval to add JitPack to the firewall whitelist, which sometimes hard to get approved. I understood that you've left everit-org and cannot access the artifactory, why not create a new project on sonatype with a different group name?

Again thanks for the awesome library.

[erosb]

Hello @JakimLi , thanks for your kind words.

The process to deploy an artifact to the central repository is simpler now as it used to be, so I published the latest version as com.github.erosb:everit-json-schema:1.9.2 . I'd still like to keep jitpack as the primary distibution channel though.

[raphw]

Have you considered to publish on Maven Central via Bintray? Publishing to Bintray is quite easy and from there you can synchronize to Maven Central by pushing a button.

I have the same issue as others, I cannot use JitPack because of firewalls and intermediate repositories. I fully understand that you want to keep the costs low but I think a lot of people would appreciate if you spent the time to set up Bintray with Maven Central synchronization.

This is more or less all I need for it in my project: https://github.com/raphw/byte-buddy/blob/master/pom.xml#L369 - Finally, I also my API key in settings.xml and run mvn release:prepare release:perform. After that I confirm the release in the Bintray web interface and press "sync to Maven".

Thanks for your efforts and code. I hope you can reconsider this if it becomes easier.

[erosb]

Hello @raphw , currently we distribute the library on maven central too, though it lags a bit behind the jitpack version. The latest coordinates are com.github.erosb:everit-json-schema:1.9.2