On 27/05/2014 15:42, Bolz, Michael wrote:
Hi together,

I started to take a look into the JSON Serialization for the server use case.

Therefore I checked the "JSONEntitySerializer" in the commons package and found 
following points which could be improved:
   * The common Entity (JSONEntity and AtomEntity) with the separated Property 
and Value interfaces is complex and overloaded. Perhaps this could be improved 
by reducing (merge?) Property and Value to a single class.

Value is also used for instance annotations (via Valuable), here's why Property and Value are separated.

Furthermore the JSONEntity and AtomEntity could be merged into a single Entity.

The only reason why JSONEntityImpl and JSONEntityImpl exist is for usage with Jackson annotations: as you can see, both barely extend AbstractEntity.

   * The use of the Jackson ObjectMapper (in JSON case) seems not necessary. Perhaps the 
AbstractODataSerializer could use the "JSONEntitySerializer" similar to the 
"AtomSerializer" (This would also help in merging JSONEntity and AtomEntity by removing 
the @Json* annotations).

It seems feasible.

And following points are missing but necessary for server usage:
   * Use of an existing EDM for type information (instead of setting and/or 
guessing type like in client use case)

On client-side this is done at higher level, in the ODataBinder implementations, when an EdmEnabledODataClient instance is being used, as opposite of plain ODataClient.

   * Differentiation between the metadata output formats 
"json-full/-minimal/-none"

Based on above points I think about the creation of an own JSON Serializer for 
the server.

WDYT?

I don't see any issue with it: only consider that besides client code, also the FIT static servers are using the commons (de)serializers.

Regards.

--
Francesco Chicchiriccò

Tirasa - Open Source Excellence
http://www.tirasa.net/

Involved at The Apache Software Foundation:
member, Syncope PMC chair, Cocoon PMC, Olingo PMC
http://people.apache.org/~ilgrosso/

Reply via email to