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/