Re: [ecf-dev] Issue adding custom serialization to ecf provider

[slewis@xxxxxxxxxxxxx]

> Hi Scott,
>
>
>>
>> I've opened, fixed, and closed bug:
>>
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=516074
>>
>> This will be in ECF 3.13.6/Oxygen due this week.
> Great! Thank you.
>>
>> One thought:   Any chance to get a bundle or two...using kyro for
>> serialization...contributed to ECF?  Perhaps via the github site [1].
> Sure, i can do that.
>
> Some points regarding that:
>
> 1) consuming kryo / target platform
>
> i don't know a public p2 update site from where to consume kryo. i do
> use a package drone instance where i imported kryo from maven central
> (which triggers p2 metadata generation). how should one provide a target
> platform for such an example?

I believe that with Tycho it's possible to include maven central
dependencies either in a target platform.  One possible problem:  does the
kyro distribution include OSGi meta-data?  (i.e. are the kryo libs/jars
already bundles?  Or do you create them/wrap them?

Another possibility:  Submit a request to Orbit to build Kyro as a bundle.
 Problem with that is that unless someone is ready to become an Orbit
committer, it's likely not to happen because someone has to maintain the
bundle in Orbit (new versions, etc).  I would happily offer to contribute
to this, but I don't think I can take on the whole thing.

>
> 2) example or implementation
>
> do you think of providing an example (or modify an existing example) or
> a general (plugin) implementation to use kryo serializer with "ecf
> generic provider"?

Yes, if that can be done it would be terrific.  I'm willing to work with
you on that if you like (e.g. modifying existing examples).

>
> 3) kryo classloading / osgi
>
> currently the bundle in which the serializer implementation lives (of
> course) needs to know all classes that need to be
> serialized/deserialized. That means that bundle has some package-imports
> which are specific for that use case which are registered with Kryo.
>
> For a more "general"/dropin solution there would be the problem to get a
> classloader that knows the domain  objects that the application uses for
> ecf/serialization. is there a classloader that knows "all" classes in
> the osgi runtime (ie. which are exported by some bundle)?

No there's no such classloader.   It is possible to add classes/libs to
the boot classloader, but that's not really a good solution for a number
of reasons.

For deserialization it's always possible to use OSGi's
Dynamic-ImportPackage: <packages> or *

This is used in several of ECF's distribution provider (e.g. generic) so
that the distribution provider can deserialize arbitrary classes, only in
packages that have been exported.  It can be in your distribution provider
as well (or even in Kyro bundles).

A problem with this, however, is that it has trouble with multiple
versions of serializable class (as is possible, of course with OSGi).  
ECF has some utility classes (e.g. IClassResolver and BundleClassResolver
in

http://git.eclipse.org/c/ecf/org.eclipse.ecf.git/tree/framework/bundles/org.eclipse.ecf/src/org/eclipse/ecf/core/util

these allow one to delegate deserialization/classloading to a specific
bundle/bundles (which can be wired to specific versions of classes).  This
can also be used to secure object deserialization.

ECF's impl of the OSGi RSA spec (remote services) uses the
*client*/service consumer Bundle to load classes...i.e. the service
interface class, the argument classes and return value classes.   So if
these classes are visible to the service consumer (as they likely should
be), then wrt remote services those classes will be loaded.

With classloading, osgi and deserialization there's lots to discuss, and
we can certainly do that if you like.

>
> 4) timeline
>
> I 'll be away from next week on till the end of june - so that will need
> to wait until i'm back, but i'll put that on my todo list ;)

Of course.   It would be nice if it was available sometime around the
Oxygen release (June 26th or thereabouts), but even if later it would be
terrific.

Thanks much,

Scott