[ 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)