[
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 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://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
(v6.3.4#6332)
