jsoncpp is having trouble reading my Gson output - json

I have a java application that outputs data in Json format (via Gson). I write that data to a file. That file is then read by a C++ application. The C++ application is using jsoncpp to deserialize the json. However, it appears that the C++ application cannot properly deserialize the Json (which is the whole point of using Json).
The problem seems to relate to the class name being included in the Gson output. Gson output sample:
{"nameOfClass":{"fieldName":"fieldvalue","secondFieldName":1}
As far as I can tell, "nameOfClass" is throwing off jsoncpp. Perhaps my jsoncpp deserialize method is incorrect? I have specific code to handle the different fields, but nothing that specifically handles that initial class name. Is that something I need to handle?

Short answer: user error
Longer answer:
It turns out I was serializing the wrong object. The class of this object CONTAINS a field of type "nameOfClass". What I wanted was that FIELD to be serialized, not the whole object. Because of my inexperience with Json and unfortunate choice of the field's name, I thought the output was malformed. Once I got the field from the object and serialized that, everything was fine.

Related

VBJSON for VB6 how to serialize object returned from Parse routine

So there is a nice library for VB6 JSON parsing. HERE
but i actually used one that built on the original and optimized. HERE
Essentially I'm using the parser to deserialize the json i get from a web service. I need to update some values, and resend to the server. Using the Collection/Dictionary objects made it very easy. But now, How do i take those objects and serialize them to a JSON string? is there a library for that?
thanks you for your help.
There are quite a few JSON parser/serializer/DOM classes written in VB6. Perhaps you might want to consider one of those instead. E.g.:
JsonBag, Another JSON Parser/Generator

Debugging json4s read deserialization errors

I am attempting to consume an API that I do not have control over which is somewhat poorly documentented and somewhat inconsistent. This means that sometimes, the API returns a different type than what is documented or what you would normally see. For this example, we'll look at a case when an array was returned in a place where I would normally see a string. That makes a crappy API, but my real problem is: How can I more easily track those things down? Right now, the errors look something like this:
No usable value for identifier
Do not know how to convert JArray(List(JString(3c8723eceb1a), JString(cba8849e7a2f))) into class java.lang.String
After deciphering the problem (why JValue::toString doesn't emit a JSON string is utterly perplexing to me), I can figure out the API returned an array when I made my case class only able to deal with Strings. Great. My issue is that finding this discrepancy between my object model and the contents of the JSON seems significantly more difficult than it should be.
Currently, this is my workflow for hunting down decoding errors:
Hope bad data has some sort of identifying marker. If this is not true, then it is way more guesswork and you will have to repeat the following steps for each entry that looks like the bad bits.
Go through the troubles of converting the JArray(List(JString(...), ...)) from the error message into valid JSON, hoping that I encode JSON the same way at the API endpoint I got the data from does. If this is not true, then I use a JSON formatter (jq) to format all data consistently.
Locate the place in the source data where the decoding error originates from.
Backtrack through arrays and objects to discover how I need to change my object model to more accurately represent what data is coming back to me from the API.
Some background: I'm coming from C++, where I rolled my own JSON deserialization framework for this purpose. The equivalent error when using the library I built is:
Error decoding value at result.taskInstances[914].subtasks[5].identifier: expected std::string but found array value (["3c8723eceb1a","cba8849e7a2f"]) at 1:4084564
This is my process when using my hand-rolled library:
Look at the expected type (std::string) compared with the data that was actually found (["3c8723eceb1a","cba8849e7a2f"]) and alter my data model for the path for the data in the source (result.taskInstances[914].subtasks[5].identifier)
As you can see, I get to jump immediately to the problem that I actually have.
My question is: Is there a way to more quickly debug inconsistencies between my data model and the results I'm getting back from the API?
I'm using json4s-native_2.10 version 3.2.8.
A simplified example:
{ "property": ["3c8723eceb1a", "cba8849e7a2f"] }
Does not mesh with Scala class:
case class Thing(property: String)
The best solution would be to use Try http://www.scala-lang.org/api/current/#scala.util.Try in Scala, but unfortunately json4s API cannot.
So, I think you should use Scala Option type http://www.scala-lang.org/api/current/#scala.Option .
In Scala, and more generally in functional languages, Options are used to represent an object that can be there or not (like à nil value).
For handle parsing failures, you can use parse(str).toOption, which is a function that return an Option[JValue], and you can doing a pattern matching on the resulting value.
For handling extraction of data extraction into case classes, you can use extractOpt function, to do pattern matching on the value.
You can read this answer : https://stackoverflow.com/a/15944506/2330361

serviceStack.Text .ToJson extension method option to output empty array for null list<T> property

There's a bit of work to set the stage, so please bear with me...
I'm using knockout to databind a rather deeply nested data structure. When I retrieve the data from the database (from MongoDB using the Mongo C# Driver) there are nested properties (of type List<T>) that aren't populated and are returned as null. I'm using the ServiceStack.Text .ToJson extension method to serialize this data structure to JSON that gets passed to the client for knockoutMapper to convert into my observable viewModel. All goes well, except for the List<T> properties that were null on the server. Since they arrive at the client with a null value, knockoutMapper just makes them observables instead of observableArrays. Now for the question... Is there any way to tell ServiceStack that I want any property of type List<T> that is empty to be serialized as an empty array? I've dug through the JsConfig object to find a setting that looks like it might help but haven't had any luck. Am I missing something in JsConfig or is this something I should be doing in knockoutMapping on the client?
EDIT: Just a note - this is a side project where I'm learning 3-4 new technologies and I have come to see how absurd it is to retrieve JSON from Mongo, use the C# driver to convert this to a POCO to work with it on the server, then to use serviceStack to serialize the POCO as JSON. I plan on changing this with a straight through shot of just JSON, but this is a learning process for me.

Json.NET - preserve type information when type is unknown

I would like to send Json to the server, and we do that with Newtonsoft's Json.NET1. The json may contain type information ("$type" = ...). This type info may point to an unknown type. Said object would typically be contained in a property of type object.
What I would like to do:
Convert the part of the unknown type to a JObject
Preserve somehow the type information, so I can send the same json back to the client at a later point as it was passed to the server.
What I've tried so far
By replacing the SerializationBinder on the JsonSerializer, I can force Json.NET to deserialize the json contained into a JObject. This is almost what I would like to have, alas the $type property is lost.
In the binder returning a type that points to an object that would work in harmony with a custom JsonConverter which would gobble up the offending object such that upon write it would faithfully recreate the json as it was encountered. However, when you hit the $type info, no converters will be called anymore, apparently we are then in a different branch of the json.NET code
One can handle a serialization error, try to read from the reader the offending part, then one could create a JOBject manually and annotate the type information.
1) More specific - the built of it that is contained in the RavenDB.Abstractions, but hopefully they have not diverged too much.

Is there a way to tell GSON to parse strings with type names at beginning?

from Jersey a classic JSON output of List looks like:
{"SubtaskType":{"id":"4","name":"mozaika","metric":"m2","code":"104"}}
But GSON will say it's not a JSON array and experimentally, it accepts:
{"id":"4","name":"mozaika","metric":"m2","code":"104"} for single SubtaskType.
I tested it with JSON validator and it seems that both forms are acceptable.
GSON's output of List looks like:
[{"name":"aa","metric":"m2","id":1,"code":200},{"name":"bb","metric":"m","id":2,"code":300}]
Is there a way to configure GSON to parse/generate the longer form (with type name)?
Edit:
This is the structure (added for change/discussion):
public class SubtaskType {
private int id;
private String name;
private String metric;
private int code;
//getters & setters
}
Note: This answer is based on the original version of the question.
from Jersey a classic JSON output of List looks like:
{"SubtaskType":{"id":"4","name":"mozaika","metric":"m2","code":"104"}}
Really? That's not a JSON array, i.e., list. It's an object with one element named "SubtaskType", for which the element's value is an object with four elements. There is no list.
Is that just what a list with a single component comes out like? Does a list with two components come out like
{"SubtaskType":[{"id":"4","name":"mozaika","metric":"m2","code":"104"},{"name":"bb","metric":"m","id":2,"code":300}}
If this is the case, and you must receive such poorly-generated* JSON, and you must use Gson, then you'll have to implement custom deserialization processing to handle the situation where it's sometimes a list and it's sometimes an object. This is an all-too-often occurring problem. Gson unfortunately does not yet have a simple configuration available to handle this often-occurring problem. I posted an example of such custom deserialization processing in response to the question at Parsing JSON with GSON, object sometimes contains list sometimes contains object
* Just because it's valid JSON, doesn't mean it's not crap. An API should generate consistently-structured JSON. Anything less is crap.
GSON's output of List looks like:
[{"name":"aa","metric":"m2","id":1,"code":200},{"name":"bb","metric":"m","id":2,"code":300}]
Good. That's what a list in JSON is supposed to look like.
Is there a way to configure GSON to parse/generate the longer form (with type name)?
Yes. The specific solution depends on what your Java data structure currently looks like, and whether you're able to change the structure to match the desired JSON. If you cannot change the Java data structure accordingly, then you must custom process serialization/deserialization. Post the Java data structure you'd like to use, and indicate whether it can be changed.
Also, post an exact example of the "longer form" JSON you want to generate that represents a list with at least two components. You have not done this, yet. So, it leaves me guessing about what you really want to do.
It does seem pretty clear that you want polymorphic type handling in whatever the ultimate solution is. This will require custom deserialization processing, if using Gson.
Regarding any question on polymorphic deserialization, please note that the issue was discussed a few times on StackOverflow.com already. I posted a link to four different such questions and answers (some with code examples) at Can I instantiate a superclass and have a particular subclass be instantiated based on the parameters supplied.
For polymorphic serialization, not only will it likely be necessary to implement custom serialization to generate the desired type element, but convincing Gson to serialize all of the fields from polymorphic types also requires custom processing. See Serializing List of Interfaces GSON for more information.