-
Notifications
You must be signed in to change notification settings - Fork 396
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Ability to use an opaque namespace? #19
Comments
Hello, First, thank you for the appreciative comments! There is a hack in the code, in JsonRef, so as to deal specifically with I have two questions:
// Note the final /
new JsonSchemaFactory.Builder().setNamespace("resource:/base/path/to/schemas/") ? |
Aha! - I knew I had to be missing something stupid simple. Yes, using a I will admit that the idea of an opaque URI was new to me when starting this, so I have to rely on the Javadoc:
vs a hierarchical:
So in this case we have 2 URIs: Thank you so much for the quick pointer! |
Glad to know it worked! However, I still think there is a bug. You can, indeed, do: final JsonSchema schema = factory.fromURI("jar:file:/foo/bar.jar!/path/to/schema"); and, in this case, I have to think abouti it some more. |
The test which breaks is due to a difference in behavior between: factory = JsonSchemaFactory.defaultFactory(); schema = factory.fromURI("jar:/foo.jar!/a/b.json"); and: factory = new JsonSchemaFactory.Builder() .setNamespace("jar:/foo.jar!/a/").build(); schema = factory.fromURI("b.json"); While the first solution will use the base URIDownloader and succeed, the second one will fail since SchemaRegistry does not use JsonRef, which has a hack for jar relative resolution, but URI resolution -- and resolving any URI against an opaque URI, which "jar" URIs are, leads to the URI given as an argument. First highlighted in issue #19. Signed-off-by: Francis Galiegue <fgaliegue@gmail.com>
Probably the last 1.1.x release. * Rework JsonRef. This fixes bugs #19, #20. * Rename FormatSpecifier to FormatAttribute. * Javadoc updates. In particular, mention the "id" conundrum, and why this implementation chooses to ignore section 5.27. Francis Galiegue (16): M{in,ax}PropertiesKeywordValidator: fix javadoc Large renaming: format specifier --> format attribute Add skeleton test file for opaque namespace testing JarNamespaceValidationTest: test that one scenario works JarNamespaceValidationTest: improve code JarNamespaceValidationTest: devise test which does not work, but should "Fix" issue #20, the ugly way Introduce JsonLocator class and implementations, plus tests JsonRef: rename .asURI() to .toURI() More tests to catch malformed "jar" URLs JsonRef: method rename Rework JsonRef Remove JsonLocator, now unneeded JsonRef: simplify code a little Inspections pass, some nitpicks fixed Various Javadoc updates Signed-off-by: Francis Galiegue <fgaliegue@gmail.com>
First I must say that after experimenting with other JSON libraries I am thoroughly impressed with this project, and thank you for it. It's simple to use and works great.
Is there a way that I'm missing, or do you have any thoughts on having an opaque namespace for schemas? I hate to talk to generics, so here's the specific use case -
Our schemas $ref each other with relative links - in this case all sit inside a folder. That folder is packaged inside the jar. I then create the factory and set the namespace similar to:
Unfortunately, during validation this fails, because of the line in SchemaRegistry.get():
Because
namespace
is an opaque URI in this case (jar:file:/<path>!/schemas/
), the Java URI API simply returns the value of theuri
parameter.A simple hack I've done to get around it is to change SchemaRegistry and basically concat
namespace + uri
, but I wanted to see if there was a more elegant way to do this, or a reason why not.Thanks for the feedback.
The text was updated successfully, but these errors were encountered: