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 Wed, 14 Sep 2016 07:49:20 GMT

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

Mime
View raw message