I am trying to create a serialization layer which allows me to:
Store my classes in a MongoDB data source
Convert them to JSON to use them in a REST API.
Some classes are clearly not case classes (because they are inherited from a Java codebase) and I would have to write ad-hoc code for that. Is registering a BSON Hook for my non standard type the correct approach, and does it provide Json serialization?
Salat maintainer here.
You might prefer to create a Salat custom transformer instead of registering a BSON hook with Casbah.
See simple example and spec.
If you run into any issues, feel free to ping the mailing list with a small sample Github project that demonstrates what isn't working.
Related
I want to parse JSON data from a RESTful service.
Unlike a SOAP-based service, where a service consumer can create stubs and skeleton from WSDL, in the case of the RESTful service, the service consumer gets a raw JSON string.
Since the service consumer does not have a Java object matching the JSON structure, we are not able to use the JSON to Java Mappers like GSON, Jackson etc.
One another way is to use parsers like JsonPath, minimal-json, etc which help traversing the JSON structure and read the data.
Is there any better way of reading JSON data?
The official docs for Jackson mention 3 different ways to parse a JSON doc from Java. The first 2 do not require "Java object matching the JSON structure". In Summary :
Streaming API (aka "Incremental parsing/generation") reads and writes JSON content as discrete events.
Tree Model provides a mutable in-memory tree representation of a JSON document. ObjectMapper can build trees that consist of JsonNode nodes.
Data Binding converts JSON to and from POJOs based either on property accessor conventions or annotations.
With simple data binding you convert to and from Java Maps, Lists, Strings, Numbers, Booleans and nulls
With full data binding you convert to and from any Java bean type (as well as "simple" types mentioned above)
Another option is to generate Java Beans from JSON documents. You mileage may vary and you may/probably will have to modify the generated files. There are at least 5 online tools for that purpose that you can try:
http://www.jsonschema2pojo.org/
http://pojo.sodhanalibrary.com/
https://timboudreau.com/blog/json/read
http://jsongen.byingtondesign.com/
http://json2java.azurewebsites.net/
There are also IDE plugins that you can use. For instance this one for Intellij https://plugins.jetbrains.com/idea/plugin/7678-jackson-generator-plugin
The GSON supports work without objects, too. Something as this:
JsonObject propertiesWrapper = new JsonParser().parse(responseContent).getAsJsonObject();
assertNotNull(propertiesWrapper);
propertiesWrapper = propertiesWrapper.getAsJsonObject("properties");
assertNotNull(propertiesWrapper);
JsonArray propertiesArray = propertiesWrapper.getAsJsonArray("property");
assertNotNull(propertiesArray);
assertTrue(propertiesArray.size()>0, "The list of properties should not be empty. ");
The problem is that the work this way is so inconvenient that it is really better to create objects instead.
Jackson has absolutely the same problems, and to greater extent - extremal inconvenient for direct json reading/creation. All its tutorials advice to use POJOs instead, too.
The only really convenient way is use Groovy. Groovy works as an envelope on Java, you can simply write Java code and use Groovy operators at need. And in JSON or XML reading and creation Groovy is incomparably more powerful that Java with all its libraries multiplied on each other! It is even much more convenient than already prepared by somebody else tree structure of ready POJOs.
My program stack is ReactiveMongo 0.11.0, Scala 2.11.6, Play 2.4.2.
I'm adding PATCH functionality support to my Controllers. I want it to be type safe, so that PATCH would not mess the data in Mongo.
Current dirty solution of doing this, is
Reading object from Mongo first,
Performing JsObject.deepMerge with provided patch,
Checking that value can still be deserialized to target type.
Serializing merged object back to JsObject, and check, that patch contains only fields that are present in merged Json (So that there is no trash added to the stored object)
Call actual $set on mongo
This is obviously not perfect, but works fine. I would write macros to generate appropriate format generalization, but it might take too much time, which I currently lack of.
Is there a way to use Playframework Json macro generated format for partial entity validation like this?
Or any other solution, that can be easily integrated in Playframework for that matters.
With the help of #julien-richard-foy made a small library, to do exactly what I wanted.
https://github.com/clemble/scala-validator
Need to add some documentation, and I'll publish it to repository.
An automated system is going to feed the application[Play with Scala] with JSON's and the contract of the integration is that there would be no validation required on JSON's since it will be always deemed right. But for testing purposes when we seed the data more often than not we are not able to send the correct JSONs. We would like to validate the JSON's we receive based on a set of grammars. Is there a library that already does this. Or is there a better way to do this?
Example: Grammar for valid Json :
"header"->[String, mandatory],
"footer"->[String],
"someArray"->Array[String, mandatory],
"someArrayObject"->Array[
{
{"key1"->Int, mandatory},
{"key2"->String}
},
mandatory
]
and passing,
{
"header":"headerContent",
"footer":"footerContent",
"someArray":["str1", "str2"],
"someArrayObject"->[
{"key1":4, "key2":"someStringValue"},
{"key1":5, "key2":"someOtherStringValue"}
]
} // would pass
{
"header":"headerContent",
"footer":"footerContent",
"someArray":["str1", "str2"]
} // would notpass since someArrayObject though declared mandatory is not provided in the sample json
I think play-json will satisfy you play-json
In play-json you don't create a validator as it is, but a json transformer which is a validator in itself. The author of the framework wrote a series of blog-posts to show how to work with it: json-transformers
* Haven't noticed you use play) Play has play-json included by default.
You don't have to roll out your own DSLs. This is why we have schemas. Just like using XML schemas to validate your XML docs, you can define a JSON schema to validate your JSON objects. I had a similar requirement when building a RESTful web service using Play. I solved it by using the JSON Schema Validator library.
I have used the JSON Schema draft v3. The library supports draft v3 and draft v4. You can validate your schemas against possible JSON inputs using a web application that uses the same library. The web app is hosted here.
Also there are pretty nice examples that use the draft v4. You can check them out from here.
In Play 2, I have composed an action that takes the schema resource file name as input. This keeps away a lot of JSON validation code from the controller action itself.
#JsonValidate("user-register.json")
public static Result create() {
...
}
This way, all JSON Validation code stays in one place. Pretty neat :)
As Horst Keller mentioned in his ABAP and JSON post, "with Releases 7.02 and 7.03/7.31 (Kernelpatch 116) JSON is supported natively in ABAP".
Appartently 7.02 in my case of too generic because the line below:
writer = cl_sxml_string_writer=>create( type = if_sxml=>co_xt_json ).
returns the error: "The field CO_XT_JSON is unknown, but there is a field with the similar name CO_XT_XOP".
So is there any way to easily generate JSON?
Edit: Screenshot from SAP - Status
About the class CL_TREX_JSON_SERIALIZER: I also used this class during developping a mobile sap application and I found the created JSON not being valid, thus I started googling and found this http://scn.sap.com/community/mobile/blog/2012/09/24/serialize-abap-data-into-json-format (which also explains how to create a valid JSON serializer).
Validate your json with json lint http://jsonlint.com/ to see if it is valid.. otherwise, thats for sure, you get a lot of trouble in debugging why it doenst work and dont get the point that the serializer is corrupt. regards, zY
take a look at the ZCL_MDP_JSON Library. You can parse/encode any JSON. So, it is best suited for JSON scenarios that requires flexibility.
It is easy to understand if you have used JSON in other languages. You only need to study methods of ZCL_MDP_JSON_NODE class once & look at the examples.
Here is an extended overview of the library:
http://scn.sap.com/community/abap/blog/2016/07/03/an-open-source-abap-json-library--zclmdpjson
GitHub repo with examples directory: https://github.com/fatihpense/zcl_mdp_json
Disclaimer: I'm the author of the project. If you have questions, don't hesitate to contact me.
Here is some code I wrote for ABAP data <-> JSON conversion some time ago before the new capabilities were included with ABAP (or maybe it was just an older system).
https://gist.github.com/mydoghasworms/2291540
Include the code in your ABAP source and use the method data_to_json of the class.
A nice overview of custom ABAP <-> JSON serializers including yet another one can be found in this blog post
Most popular from my point of view is SE38's ZJSON-library which can be installed using SAPLINK (and which - in contrast to many others) has an explicit license attached to it: Apache 2.0
If upgrading to a newer patch isn't an option in the short term, you can also use class CL_TREX_JSON_SERIALIZER to serialise objects to JSON. A little bit of a quick-and-dirty solution but it works well.
In my GWT project I need to process json data retrieved from a database via PHP. I have seen the Google examples using JavaScriptObject overlay classes. What I don't understand is why this seems to be the prefered method of processing the json data. Why shouldn't I use all native Java code to pull in the data?
Think about it the other way around: what does it mean to use POJOs? (or native Java classes as you name them)
You have to:
parse the JSON into some Java-accessible structure (e.g. com.google.gwt.json.client.JSONObject, or elemental.json.JsonObject)
create POJOs
fill the POJOs with the data from the parsed JSON structure
now you can forget the parsed JSON structure from step 1
On the other hand, with JavaScriptObject, you use JsonUtil.safeEval and TA-DA! you get your JSON parsed right into a typed Java object!
Now, to deal with JSON, there's also AutoBeans.
Choose your poison.