Hi Kevin, your idea of using a custom deserializer instead of pure annotations sounds very good to me. This would make it easier to first deserialize the existing schemas and then move to the type definitions afterwards. This way you already have the schema CSDL classes ready and can attach the types as you deserialize them. I am looking forward to a first prototype ☺
About the general architecture: I would suggest that the deserializer should not validate the document it is parsing for semantics. This means that if a server sends a metadata document that contains an entity set with a type that is not present we do not throw an exception during parsing. This is to save performance for bigger metadata documents and also because a server should always send a valid metadata document. WDYT? Best Regards, Christian From: Kevin Ratnasekera [mailto:djkevincr1...@gmail.com] Sent: Samstag, 4. Juli 2015 21:49 To: dev@olingo.apache.org Cc: Amend, Christian; amend.christ...@gmail.com Subject: JSON Metadata Document client side deserializer Hi Olingo Community, Regarding the Json metadata document GSoC project currently I have progressed upto the metadata document serialization at the server side. [1] Now I have moved implementation of client side metadata document de-serialization. When I have look at the current Service Document Json deserializer and metadata document xml deserialzer in client core lib, the approach which is used to deserialize either Json and xml payloads of metadata/service document is writing custom Jackson deserializer classes. For the Json service document a single custom deserializer ( JSONServiceDocumentDeserializer ) is being used, and for the xml metadata document case set of deserializer classes for parts of metadata document (EntityContainerDeserialize, ReferenceDeserializer) and they are registered on jackson mapper object using annotations first and then called recursively when we go through the each element of metadata document when parsing the relevant payload. I am thinking of adapting the similar approach to Json metadata document deserialization, basically to write Jackson custom deserializer classes for json metadata document elements similar to xml case ( but there are some changes documents). I see some advantages of this basically this approach is complaint with the current approach, custom deserializer classes are more robust and adaptable complex custom cases when compared to approaches just simply use Jackson annotations to map json fields to java object fields. Are there any other approaches available to achieve this? And What should be the best approach to use? Regards Kevin [1]https://github.com/djkevincr/olingo-odata4/tree/jsonMetadata
