I'm having some troubles serializing polymorphic collections with spring hateoas.
After setting all the mappings in the POJOs I can serialize single resources correctly, but when it comes to collections I cannot do it. From what I've seen, when dealing with collections we have to set the type reference we're dealing with, but when it comes to Spring that stuff is done internally. I could override the ObjectMapper to deal with this, but it doesn't seem a good idea... What have you people been doing to solve this issue? And again, this only happens with collections not with single resources so it's not a problem of annotation configuration on the POJOs.
Any thoughts?
Related
I'm trying to implement a logic that serializes and de-serializes a very complex legacy object. The object contains other complex objects inside of it that are spread through various other projects. There are even some JAXB1 objects that are generated from an xsd schemas and are part of the chain.
Right now there is already a working version that uses XStream and this worked for years. But since Java 17 there are issues because of the new restriction for using reflection on private fields from different modules. Exceptions like this started to appear ->
Module {A} does not 'opens {package}' to {B}". One of the things that bothers me is that all of these packages are from some third party libs and I even can't find any objects from them in the model chain.
So I started implementing a new serialization based on the Jackson databind API but right now I'm wondering is it going to solve the issues at all? Does Jackson also use reflection in case to serialize and de-serialize? What is the best way to configure the ObjectMapper and what should I change in the objects that I need to work with in case to make the reflection usage as low as possible?
Right now I've configure the ObjectMapper as:
objectMapper.disable(MapperFeature.AUTO_DETECT_CREATORS,
MapperFeature.AUTO_DETECT_FIELDS,
MapperFeature.AUTO_DETECT_GETTERS,
MapperFeature.AUTO_DETECT_IS_GETTERS);
objectMapper.disable(SerializationFeature.FAIL_ON_EMPTY_BEANS);
and I'm annotating all fields that should be serialized with #JsonProperty but I'm not sure that this is going to help. Okay, I assume I must have getters and setters, but should I also annotate them? Does the annotation has something to do with the reflection usage at all?
Looking for some help to serialize a deep nested java objects to Json. The constraint is that I cannot add any annotations or change the current Java code. Looking for a powerful Json library which has configuration options to convert Java to Json without altering the Java Object themselves. Following would be some of the options that might be required
Specify include/exclude fields/methods. Should be able to specify this at nested levels. A is composed of B and B is composed of C. Should have ability to specify include/exclude at C.
Include/Exclude Objects at nested levels.
Rename fields from java properties while converting to Json (at nested level objects too)
Manager circular dependencies.
Was looking at Jackson and Gson for this requirements. While there are tons of options using annotations to specify serialization configs while writing new Java Pojo's, I am looking at options where I need to specify serialization properties without changing the current Java code. Jackson and Gson do seem to have options for these, but not documented in depth.
Which library is easier to configure for the above requirements? Any other powerful library other than Jackson/Gson? Any pointers to this will be of great help.
Thanks much for your time.
As to Jackson, you might consider using so-called mix-in annotations (see f.ex http://www.studytrails.com/java/json/java-jackson-mix-in-annotation.jsp) which allow you to specify mix-ins to use, without adding them directly in the legacy classes.
This would let you use annotation-based configuration, but leave actual classes untouched.
But given all of your requirements, it may perhaps be better to just use Tree Model of Jackson or GSON (get JsonNode or such), and manually handle conversions to your liking.
You may then be able to convert tree value into POJO; Jackson, for example, has method(s) for doing this (ObjectMapper.treeToValue(), .valueToTree(), .convertValue()) which allow conversions of structurally compatible representations.
Is there a way to perform serialization/deserialization in Jackson of polymorphic classes w/out using annotations or specialized bean fields? I have to support class hierarchies that I cannot modify and don't wish to use annotations.
I'd like to be able to designate a synthetic name, which would not be in the classes that I am serializing/deserializing, that would be inserted into the JSON representation and used to identify the type.
If mix-ins are not to your liking, there isn't anything pre-defined to pass, but you can relatively easily achieve this by sub-classing JacksonAnnotationIntrospector and configure mapper with it.
In your implementation you can override all aspects of annotation access: in your case it's probably enough to override findTypeResolver() (and if you want per-property overrides, 'findPropertyTypeResolver()').
The method can then use whatever mechanism you want to construct TypeResolverBuilder (most likely StdTypeResolverBuilder) that contains same information as what would usually come from #JsonTypeInfo annotation.
For anyone looking for polymorphic json unmarshaling problems, you should check out this post, which gives great examples & workarounds for JSON serialization / deserialization caveats.
And if mixins (step 5 at the above mentioned post) is not what you're looking for than go for the accepted answer by StaxMan.
The custom BeanSerializerFactory in http://kyrill007.livejournal.com/2577.html is the only custom solution I found to allow directly throwing persistent beans to JSON via Spring 3.0, and it works, it only serializes non initialized (lazy) attributes / collections (this allows me to use the entity Pojo as a DTO, as I initialize only what I want, and what is not initialized, doesn't get serialized to JSON)
But this worked well with Jackson 1.6, and I wanted to upgrade to Jackson 1.8 to solve the issue with Java Generics (hopefully) and now that custom solution is not compiling.
So my questions are
What is the recomended way to auto serialize Entities to JSON without the need of DTOs
Is there an official Hibernate Aware Jackson BeanSerializerFactory besides the above
I'm starting to fear that if it's that hard to find, maybe my practice is not the best one
What is the recommended way to do RESTful Ajax then with Spring 3.0 MVC and JSON?
The problems to solve are
Not serializing lazy attributes / collections automatially (as the custom code above does)
Supporting Java Generics and some kind of a client side object schema / validation
What works on get should work on save, and allow partial objects graphs to be returned safely
Is there Anything? do I have to manually write DTOs for every Entity?, this is so non productive
While SO has lots of experts, you might consider also asking on Jackson users list. Kirill (author of the blog entry) is responsive, and there are other experts there as well.
If I try to serialize a linq-to-sql entity, will it by default serialize only the primitive fields or will it try to access the relationship fields as well? If it tries to grab relationship fields, is there a way to override this?
Which serializer are you using?
The DataContractSerializer will
include loaded relationships but not
those that are not yet loaded / null.
The XmlSerializer tend to choke on relationships if they are bidirectional (i.e. entity A points to entity B which in turn points back).
The binaryformatter ... I never got that one to work properly with L2S entity objects having relationships to other entities. Long time since I tried though, so maybe I just did something wrong...
Another point to add to the accepted answer:
Relationships that are not collections will never be serialized by DataContractSerializer (whether they are loaded or not), because no DataMember attribute is generated for them from the .dbml file.
I found here an explanation by then-at-Microsoft Daniel Simmons:
The issue here is that prior to SP1 there was really no good way with DataContract serialization to handle graphs of objects that had cycles. As a result for LINQ to SQL the compromise decision was made to allow users to opt-in for uni-directional serialization and to only serialize collections not references. This mechanism doesn't work well for cases where you really want to serialize a reference (like your scenario above), but it at least gets you going for some common scenarios.
In SP1 new support was added to WCF which enables DataContract serialization to deal with cycles, but it is something you must opt-in to by changing some of your DataContract attributes and potentially also making changes to your collection and reference class implementations to properly handle the serializaiton and especially the deserialization behaviors of WCF. In the Entity Framework the changes were made to take advantage of these new features since it had not yet released its very first version, but Linq to SQL only had a small service-pack upgrade in sp1 and it was not modified to take advantage of this capability.
I have not experimented with this on L2S, but it might be possible to generate your own classes which work with L2S and have the right support for WCF serialization with cycles.
Danny