Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

generation yields unreproducible results for "additionalProperties" #40

Closed
joelittlejohn opened this issue Jun 23, 2013 · 3 comments
Closed
Milestone

Comments

@joelittlejohn
Copy link
Owner

Original author: pablo.ab...@gmail.com (February 07, 2012 13:52:26)

What steps will reproduce the problem?
1.
create the file "metadatum.json" with this content :
{
"description" : "piece of metadata",
"type" : "object",
"properties" : {
"name" : { "type" : "string"},
"value" : { "type" : "string"}
}
}

2.
in the same folder, create the file "metadata.json" with this content :
{
"description" : "group of metadata",
"type" : "object",
"additionalProperties" : {
"type" : "object",
"javaType" : "mypackage.Metadatum",
"$ref" : "metadatum.json"
}
}
3. run the generation with the maven plugin

  1. Do this on a second computer, with not exactly the same OS, JDK (and probably maven jars)

What is the expected output?

Two classes : Metadata, Metadatum. Metadata contains a Map<String, Metadatum>

What do you see instead?

on "GoodComputer", always the expected output

on "BadComputer", always Metadata and MetadataProperty (no Metadatum)

Note that the behaviour persists on both computers with or without the line
"javaType" : "mypackage.Metadatum",

What version of the product are you using? On what operating system?

Version 0.1.10 (tried to upgrade to 0.2.1 without more luck)

OS :
GoodComputer : Ubuntu 10.04.3 LTS with SUN JDK 1.6.0_26
BadComputer : Ubuntu 10.04.1 LTS with SUN JDK 1.6.0_22

both have default maven2 (2.2.1) from the ubuntu repos

Something occurred to me while writing this report, I checked it and I think I've found the cause of the problem :
Jsonschema2Pojo.generate uses File.listFiles to loop on files from the input directory.
A quick java test program demonstrated that listFiles (as documented) does not return the files with the same order : metadatum.json comes first on GoodComputer and second on BadComputer.

Original issue: http://code.google.com/p/jsonschema2pojo/issues/detail?id=40

@joelittlejohn
Copy link
Owner Author

From joelittl...@gmail.com on February 07, 2012 21:30:07
Pablo, thanks for filing this. Yes I think you're absolutely right, the non-deterministic order in which files are read is causing unpredictable output. GoodComputer reads metadatum.json first I believe, BadComputer does the opposite.

I haven't yet tried this, but I think one workaround would be to move "javaType":"mypackage.Metadatum" to metadatum.json.

Strictly speaking, all properties inside your additionalProperties schema should be ignored when the ref is resolved (this is why javaType isn't having the effect you expect). There's a thread that discusses this on the JSON Schema group[1]. The type and javaType properties should be removed from your additionalProperties schema.

I think jsonschema2pojo needs to do better here at understanding all the schemas present in a directory of schemas before starting type generation. This should remove the unpredictable behaviour.

I'll pencil this in for the next release.

[1] http://groups.google.com/group/json-schema/browse_thread/thread/5df888bfef65b54f/976606cad347b37c

@joelittlejohn
Copy link
Owner Author

From pablo.ab...@gmail.com on February 08, 2012 08:40:29
Thanks a lot for your fast answer.

Moving the javaType property to metadatum.json effectively solved my problem.

@joelittlejohn
Copy link
Owner Author

From joelittl...@gmail.com on February 25, 2012 22:44:36
I've made some changes to make sure that incoming files are processed in a predictable order. This should guarantee that the output is at least consistent across different environments (and make tracking down problems like yours much simpler).

# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

No branches or pull requests

1 participant