Coder Social home page Coder Social logo

Comments (11)

henrik-io avatar henrik-io commented on May 22, 2024 2

I finally figured it out by reading this excellent guide. So now each of my documents have an id property that contains classpath:/.../blah.json (or whatever the name of the file is). So it now looks like this:

{
  "$schema": "http://json-schema.org/draft-04/schema#",
  "id": "classpath:/json-schemas/webhook-schema.json",
  "type": "object",
  "properties": {
    "url": {
      "$ref": "url-schema.json"
    },
  "required": ["url"]
}

and the url-schema.json file looks like this:

{
  "$schema": "http://json-schema.org/draft-04/schema#",
  "id": "classpath:/json-schemas/url-schema.json",
  "type": "string",
  "pattern": "^\\s*https?://\\w+.\\w+(\\.\\w+)*.*$"
}

This seems to work great. Thanks again for the test case example, it definitely put me on the right track!

from json-schema-validator.

stevehu avatar stevehu commented on May 22, 2024 1

@Whathecode You have described a process I am following all the time to create big OpenAPI 3.0 specifications with tons of schemas. I also have a bundler to bundle all files into one openapi.yml for the light-codegen input.

I am wondering if you could create a document in the doc folder with the content above. It will help lots of other users. Thanks.

from json-schema-validator.

stevehu avatar stevehu commented on May 22, 2024

Yes. It supports multiple files; however, you cannot refer to your local file system as in JSON schema spec, the $ref is a uri and it has to refer to a web url. You have the same limitation in swagger specification as well.

The following is one of my test cases and it gives you an example on how to use remote $ref. Hope it helps. Thanks.

https://github.com/networknt/json-schema-validator/blob/master/src/test/resources/tests/refRemote.json

from json-schema-validator.

2beers avatar 2beers commented on May 22, 2024

Thanks. What I wanted was to load files relative to the main json file.
In the end I was able to achieve this using:

"$ref": "file:file2.json"

I hope you won't change this in the future, since this is very important to me.

Good job on library

from json-schema-validator.

stevehu avatar stevehu commented on May 22, 2024

Yes. That is the right syntax for file system reference. It won't be changed:)

from json-schema-validator.

henrik-io avatar henrik-io commented on May 22, 2024

Hi there. I just started playing with this library today, and ran into the same issue. I can get it to work with the "$ref": "file:file2.json" syntax shown above, but my schemas will end up in a jar file, so I would need to load the relative schema files from the class path. The json-schema-validator library supports loading schemas from the class path through resource:... which is really handy. Does your library support something similar? Thanks.

from json-schema-validator.

stevehu avatar stevehu commented on May 22, 2024

@henrik-io Could you please take a look at #45 and see if it works for you? There is an example to show you how to use it. Let me or @kenwa know if you have questions. Thanks.

from json-schema-validator.

kenwa avatar kenwa commented on May 22, 2024

@henrik-io I see that the test case added in #45 only shows how to use the classpath prefix, but you can also use a resource prefix if you prefer that. Both prefixes work in the same way.

from json-schema-validator.

henrik-io avatar henrik-io commented on May 22, 2024

Hi there @stevehu and @kenwa, and thanks for the added test. This may be more of a JSON Schema newbie question, but I just can't seem to get this to work. I'm trying to validate an instance of the first schema, and I don't get any complaints from the validator, but when I run it in the debugger, it shows that it has no schema for the "url" property. These are my two schemas:

{
  "$schema": "http://json-schema.org/draft-04/schema#",
  "type": "object",
  "properties": {
    "url": {
      "id": "classpath:/json-schemas/url-schema.json",
      "type": "string",
      "$ref": "#/url"
    }
  },
  "required": ["url"]
}

URL schema:

{
  "$schema": "http://json-schema.org/draft-04/schema#",
  "type": "string",
  "pattern": "^\\s*https?://\\w+.\\w+(\\.\\w+)*.*$"
}

Both schemas reside in my project under src/main/resources/json-schemas. What am I doing wrong? Any help would be much appreciated.

from json-schema-validator.

stevehu avatar stevehu commented on May 22, 2024

@henrik-io I am glad that you figured it out. The detailed documentation about your solution is very helpful and I am sure others will find it very helpful. Thanks.

from json-schema-validator.

Whathecode avatar Whathecode commented on May 22, 2024

I believe I struggled with a similar problem, and answering here for posterity. Perhaps some of this can be included in the documentation at some point in the future.

First of all, it is worth being aware about the advice on how to use $id. It should really be the identifier of the schema, and not the retrieval URI. (I believe henrik-io's solution goes counter that.) But it's relevant to be aware about how the retrieval URI is used to resolve $id when not present.

If you adopt a one file per schema approach, and match the .json files in the file system with that of relative $id paths, you get a lot of stuff "for free" during schema development. Therefore, I found out this is a good convention to follow.

First, I did include $id, and set it in each schema matching a fully qualified URI. I then used .uriFetcher to intercept requests to my namespace and swap them out with file: lookups.

val localSchemaFetcher =
    object : URIFetcher
    {
        private val uriFetcher = URLFetcher()

        override fun fetch( uri: URI ): InputStream
        {
            if ( uri.host == "carp.cachet.dk" )
            {
                val localPath = uri.path.replaceFirst( "/", "" )
                return uriFetcher.fetch( URI( "file:$localPath" ) )
            }

            return uriFetcher.fetch( uri )
        }
    }

val schemaFactory = JsonSchemaFactory.Builder()
    .addMetaSchema( metaSchemaVersion )
    .defaultMetaSchemaURI( metaSchemaVersion.uri )
    .uriFetcher( localSchemaFetcher, "https" )
    .build()

In fact, if you follow this convention (and you also include the .json file extension in the identifier, which I see no problem with), you can even remove all $ids. The file paths fully dictate the $id, and depending on the initial retrieval URL, everything will work. At the very least, this is great for development, but you may still want to transform the files when publishing, perhaps using a bundler (haven't used one yet).

from json-schema-validator.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.