felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Leangen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FELIX-5332) Serializer
Date Sun, 04 Sep 2016 06:43:21 GMT

    [ https://issues.apache.org/jira/browse/FELIX-5332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15462397#comment-15462397

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/converter].

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 order to maintain the same structure
and style, I literally copied the Converter 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’d like. But it’s good enough for my current needs, and also as a proof
of concept to better communicate my thoughts.

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 into the object

 - [Schematizer|https://github.com/dleangen/felix/tree/serializer/converter/converter/src/main/java/org/apache/felix/schematizer/impl]:
creates the schema 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 object (i.e. to String), and using the schema deserializes back to object (mostly
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 Serializer needs to do conversion. So in
the end, the Converter, Codec, Schematizer, and Serializer all need to come together. For
that reason, keeping them separated as they are now may not be ideal. But integrating them
would likely require updates to the API, and I don't know if that's possible. There may 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 engine for a DTO,
while the Schematizer acts more like a compiler. The Converter does a “real time” conversion,
while the Schematizer reads 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 anything in
memory. The advantage of the Schematizer is that it can be used for deserialisation, which
depending on the object structure may not be (easily) possible without a memory of the original
object graph.

The Converter is much more complex. It can act on DTOs, Maps, and interfaces. I limited the
Schematizer to act only on DTOs. It can provide a Map representation, but that’s it. If
ever this becomes interesting to somebody, I suppose that flexibility could always be added

The Schematizer can produce a serialisable version of the DTO schema. I was considering making
a quick and dirty prototype for [JSON Schema|http://json-schema.org/], but there is a bit
more complexity in there than I am willing to handle right now, so I just did a simple “custom”
JSON version of a schema. It merely reflects the state of the Schema object output by the
Schematizer. I suppose that it could be possible to implement with JXPath instead, but that
seemed a bit heavy handed to me. The purpose here is to specialise for DTOs, and to try to
keep it lightweight and free of dependencies. That said, the code is more complex than I think
it needs to be. I'm sure it could be simplified quite a bit, but this is quite a complex 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 directly)
 * Probably much more :-)

The Schematizer could eventually be used to output JSON Schema, DTDs, or XML 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 this.

> 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 the output.

This message was sent by Atlassian JIRA

View raw message