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

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

I have made another attempt. Here are a few additional learnings, and a bit of 
an explanation about what I've done. This patch (which I will submit right 
away) is up-to-date with the current version HEAD in the felix git repo.

In addition to a few API updates and corresponding implementation classes, I 
have submitted several classes in the test cases. The goal here is to mock what 
I would consider to be an epitomic use case. Here, I created a mock-up of 
Prevayler. Prevayler needs to serialize objects (normally to a file on disk), 
then deserialize the objects. Problem is, there is no way to know which object 
is being deserialized, and no knowledge about the object, so without some help, 
deserialization will not work.

To give a bit more context: each "transaction" is wrapped in an object 
prescribed by Prevayler. I created an arbitrary means of wrapping up the 
transaction as a DTO. Probably, this part needs much more thought. 
Specifically: what should go into the OSGi Serializer, and what should not. I 
think some of the stuff going on outside should actually be brought inside, 
since it is stuff that will *always* have to be done (such as providing an 
identity for a Schema to avoid having to also serialize the entire schema along 
with the payload).

I think that the Schematizer could eventually be much "smarter" and require 
fewer hints via rules, but I am running out of time. Working with rules was 
quicker for me, because it allowed me to dumb down the Schematizer.

If there is anything unclear in the code, please ask. I can also submit 
comments.

The code helps in two ways:

 #  Creates a 
[Schema|https://github.com/dleangen/felix/blob/serializer/converter/converter/src/main/java/org/osgi/service/converter/Schema.java]
 of the object to serialize, which can provide all the hints necessary to 
properly deserialize later
 # Serializes the Schema by means of an alias, so as to not take up disk space 
unnecessarily

I'm sure there is a more intelligent way to serialize the alias, but whatever. 
This works. :-)

I'm sure others will find lots and lots of improvements to make, but as I say, 
I hope at least that this will start a serious discussion.

Some limitations:

 * Only works with DTOs for now (maybe that is how it should remain, I don't 
know).
 * Code could be cleaner (but is a good starting point for discussion).
 * Introduces new objects into the API (so adoption / agreement may not be 
easy).

BTW, I find it much easier working with git than submitting patches via svn. 
[Here is the branch on my git 
clone|https://github.com/dleangen/felix/tree/serializer/converter]. Would it be 
possible to make a pull request next time instead of submitting a patch?

> Serializer
> ----------
>
>                 Key: FELIX-5332
>                 URL: https://issues.apache.org/jira/browse/FELIX-5332
>             Project: Felix
>          Issue Type: New Feature
>          Components: Converter
>            Reporter: David Leangen
>
> 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)

Reply via email to