Mailing-List: contact dev-help@felix.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@felix.apache.org
Date: Sun, 4 Sep 2016 06:43:21 +0000 (UTC)
From: "David Leangen (JIRA)" <jira@apache.org>
To: dev@felix.apache.org
Message-ID: <JIRA.12999532.1472023802000.487890.1472971401719@Atlassian.JIRA>
In-Reply-To: <JIRA.12999532.1472023802000@Atlassian.JIRA>
References: <JIRA.12999532.1472023802000@Atlassian.JIRA> <JIRA.12999532.1472023802757@arcas>
Subject: [jira] [Commented] (FELIX-5332) Serializer
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
archived-at: Sun, 04 Sep 2016 06:43:23 -0000


    [ https://issues.apache.org/jira/browse/FELIX-5332?page=3Dcom.atlassian=
.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D1546=
2397#comment-15462397 ]=20

David Leangen commented on FELIX-5332:
--------------------------------------

I have done some experimenting. Overall conclusion: possible, but much more=
 "complicated" than I had expected.

Related code is [here|https://github.com/dleangen/felix/tree/serializer/con=
verter].

I did not want to interfere with the current code base, so I created a few =
additional services that work in conjunction with Converter and Codec. In o=
rder to maintain the same structure and style, I literally copied the Conve=
rter and Codec to Schematizer and Serializer, respectively, and refactored =
from there. In the end, I'm not sure if that was a great idea. The code is =
not as elegant as I=E2=80=99d like. But it=E2=80=99s good enough for my cur=
rent needs, and also as a proof of concept to better communicate my thought=
s.

Here are a few of the insights I gained while going through this discovery =
process.

In a nutshell, I found that there are a few different roles.

 - Converter: converts an object of one type into an object of another type

 - Codec: encodes an object to some form (i.e. String), and decodes back in=
to the object

 - [Schematizer|https://github.com/dleangen/felix/tree/serializer/converter=
/converter/src/main/java/org/apache/felix/schematizer/impl]: creates the sc=
hema based on the static structure of the DTO

 - [Serializer|https://github.com/dleangen/felix/tree/serializer/converter/=
codec/src/main/java/org/apache/felix/serializer/impl/json]: serializes an o=
bject (i.e. to String), and using the schema deserializes back to object (m=
ostly the same as Codec, but uses the schema for proper typing)

The Schematizer can schematize on its own, but in order for it to have any =
meaning, it needs to be used together with the Serializer, and the Serializ=
er needs to do conversion. So in the end, the Converter, Codec, Schematizer=
, and Serializer all need to come together. For that reason, keeping them s=
eparated as they are now may not be ideal. But integrating them would likel=
y require updates to the API, and I don't know if that's possible. There ma=
y be a smart way to somehow integrate the functionality without a major API=
 update. That would be great, but I'm not seeing it right now. Maybe after =
a few days away from the code I could look at it again with fresh eyes...

One observation I had: the Converter acts kind of like an interpretation en=
gine for a DTO, while the Schematizer acts more like a compiler. The Conver=
ter does a =E2=80=9Creal time=E2=80=9D conversion, while the Schematizer re=
ads the static structure and keeps a record for later. The advantage of the=
 Converter (relating to this aspect only) is that you do not need to keep a=
nything in memory. The advantage of the Schematizer is that it can be used =
for deserialisation, which depending on the object structure may not be (ea=
sily) possible without a memory of the original object graph.

The Converter is much more complex. It can act on DTOs, Maps, and interface=
s. I limited the Schematizer to act only on DTOs. It can provide a Map repr=
esentation, but that=E2=80=99s it. If ever this becomes interesting to some=
body, I suppose that flexibility could always be added later.

The Schematizer can produce a serialisable version of the DTO schema. I was=
 considering making a quick and dirty prototype for [JSON Schema|http://jso=
n-schema.org/], but there is a bit more complexity in there than I am willi=
ng to handle right now, so I just did a simple =E2=80=9Ccustom=E2=80=9D JSO=
N version of a schema. It merely reflects the state of the Schema object ou=
tput by the Schematizer. I suppose that it could be possible to implement w=
ith JXPath instead, but that seemed a bit heavy handed to me. The purpose h=
ere is to specialise for DTOs, and to try to keep it lightweight and free o=
f dependencies. That said, the code is more complex than I think it needs t=
o be. I'm sure it could be simplified quite a bit, but this is quite a comp=
lex puzzle with many moving parts.

Limitations + things to consider:

 * Only works with objects that extend DTO
 * Not thoroughly tested
 * Not well integrated with Converter / Codec
 * Perhaps Adapter is not necessary (move everything to Schematizer directl=
y)
 * Probably much more :-)

The Schematizer could eventually be used to output JSON Schema, DTDs, or XM=
L Schema etc. I did not implement that.

It could also be used to introspect a DTO, for instance if an object needs =
to be split up or joined when working with a persistence framework. I have =
not yet implemented that, either.


Look forward to hearing your thoughts about which direction to take with th=
is.

> Serializer
> ----------
>
>                 Key: FELIX-5332
>                 URL: https://issues.apache.org/jira/browse/FELIX-5332
>             Project: Felix
>          Issue Type: New Feature
>          Components: Converter
>            Reporter: David Leangen
>         Attachments: diff-serializer.txt
>
>
> Test case and a bit of code to show how a Serializer could work.
> To work as a Serializer, the type information needs to be embedded into t=
he output.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)