I'm getting "JSONRpcClientException: ... circular reference." when serializing my domain objects with JSON. (using jsonrpc1.0).
I'd like to maintain the domain as it is, but need to get JSON-RPC working so I wonder if there is any solution to avoid or skip some fields of a Java class (those circulars) of being serialized to JSON as it is described here for .NET.
Is it posible to use something like ScriptIgnore tags in Java to reach this?
Related
Due to old project decisions, I work on a project that uses Jersey to connect to services that return XML data. Sometimes I could create the bean/pojo/whatever annotated with XmlRootElement and use webTarget.get(MyPojo.class)
However, if I try to do what I would do with, say, Jackson, and do webTarget.get(Map.class) I get the following error:
MessageBodyReader not found for media type=text/xml, type=interface java.util.Map, genericType=interface java.util.Map.
My case is, I have a XML that can have arbitrary fields whithin, so the ideal way for me to read it is to read a Map. Is there any way I can do that without having to rely in other libraries? I don't need to serialize data, only deserialize responses from the web services I connect to.
Found the answer, and it's kinda depressing.
According to the Unofficial JAXB Guide, you can't use a Map as a root element, unless you do a very ugly hack, described there. So, the solutions are:
Read as a String, and use Jackson to read a Map from the string.
Do the ugly hack.
Describe part of the schema in a bean, but the part that can have variable fields can be deserialized to a Map.
I'm having a problem when serializing and deserializing my objects in my project. I'm writing the object to a name.dat file.
However whenever i make a change in the Name class i can nolonger deserialize it, since it's two different objects.
Is there any way around this?
Your best options are:
Don't change your classes :-)
Throw away any serialized objects each time you change your classes.
Don't use Java object serialization.
Given that 1) and 2) are probably out of the question, option 3) should be given serious consideration. There a variety of alternatives to Java serialization, depending on the nature of the data you are persisting. These include:
Using Java properties files
Storing the data in a classical database (using SQL and the JDBC API)
Using an object-relational database mapping such as Hibernate
Using XML or JSON and a "binding" technology so that you can serialize / deserialize POJOs.
Finally, it is possible to implement class versioning using Java object serialization. However, it is tricky. And if you are continually changing the classes, then it is not going to be pleasant. Start by reading Versioning of Serializable Objects.
Sometimes, we need to create some thrift objects in unit tests. We can do it by manually create object using Java code, like:
MyObj myObj = new MyObj();
myObj.setName("???");
myObj.setAge(111);
But which is not convenient. I'm looking for a way to create objects with some readable text.
We can convert thrift objects to JSON with TSimpleJSONProtocol, and get very readable JSON string, like:
{ "name": "???", "age": 111 }
But the problem is TSimpleJSONProtocol is write only, thrift can't read it back to construct an instance of MyObj.
Although there is a TJSONProtocol which supports to serialize and deserialize, but the generated JSON is not readable, it uses a very simplified JSON format and most of the field names are missing. Not convenient to construct it in tests.
Is there any way to convert thrift objects to readable string and also can convert it back? If TSimpleJSONProtocol supports converting back, which is just what I'm looking for
The main goal of Thrift is to provide efficient serialization and RPC mechanisms. What you want is something that is - at least partially - contrary to that. Human-readable data structures and machine processing efficiency are to a good extent conflicting goals, and Thrift favors the latter over the former.
You already found out about the TSimpleJson and TJson protocols and about their pros and cons, so there is not much to add. The only thing that is left to say is this: the protocol/transport stack of Thrift is simple enough.
This simplicity makes it possible to add another protocol based on your specific needs without much or overly complicated work. One could probably even write an XML protocol (if anyone really wants such bloatware) in short time.
The only caveat, especially vis-à-vis your specific case, is the fact that Thrift needs the field ID to deserialize the data. So you either need to store them in the data, or you need some other mechanism which is able to retrieve that field ID based on the field and structure names.
I am using Axis to call a SOAP-based web service. I'm then trying to serialize the returned remote object as JSON, using the Google Gson library.
The serialization to JSON fails, with Gson complaining that "there are multiple elements with the name __equalsCalc()).
When I inspect the returned object in my IDE (Eclipse), I can see that this is true -- the returned object has three members called __equalsCalc() and another three called __hashCode.
I know from looking around that these are added by WSDL2Java (I think) in order to avoid recursion. My question is, why are there THREE of each? And how can I get the serializer to ignore these? They're not actually part of the object's definition (it's called a RemoteProject, for reference). Can I do something hackish like cast the RemoteProject to a RemoteProject to get it to drop those members?
This turns out to be not too hard to solve. I have multiple copies of the same instance var because the class being serialized is shadowing fields of the same name from superclasses. Since I don't care about these fields, the best approach in Gson is to write a custom ExckusionStrategy which can selectively ignore fields based on their name:
http://google-gson.googlecode.com/svn/trunk/gson/docs/javadocs/com/google/gson/ExclusionStrategy.html
I don't know GSon.
With Jackson, you can annotate properties (i.e - fields that have getters/setters according to Java bean convention) with #JsonIgnore.
This way you can prevent issues like recursion/no matching setter or getter and so on...
Try to find out if you have the same at GSon or use Jackson.
I amusing Flex for front end building. I have one doubt regarding sending two array of strings from java to flex.
How can I do that?
For example I have a value object defined like below.
class Test
{
String value1[]={"1","2","3"};
String value2[]={"narendra","mani","suresh","kane"};
//Getter and setters goes here
}
Can any one help me on this?
Thanks,
Narendra
This is really a matter of how do you want Flex to communicate with your Java layer, I think the closest to a turn key solution to this is using the BlazeDS jar on the server to do the ActionScript Message Format conversion between Java DTOs and Actionscript DTOs, basically how it works is you code up the Java side then you can have it generate the Java equivalent DTOs that will be tagged with Metadata so when the Java objects are serialized and sent across the wire the client has them as typed objects.
http://opensource.adobe.com/wiki/display/blazeds/BlazeDS
Alternatively you could expose the data as XML using a JSP to generate the XML then just using an HTTPService call to the JSP to get the XML data then since AS3 makes use of E4X parsing the XML into AS3 objects is very easy, lots of examples of doing this just search for e4x AS3 for examples.
Hope this helps,
Shaun