Thanks all for the feedback.
At higher level, I see there are 2 kind of river service implementations.
1.
Service which doesn’t ask the client to download any code.(JERI)
2.
Service which ask the client to download code (smart services).
Here I describe what are all changes I made in POC for the first type of
service.
1.
I made an osgi bundle using the the river core classes as a system
fragment. So all river classes will be loaded from framework class loader.
2.
I have set the following system properties while running the osgi
container. Please refer the lookup.bndrun file.
1.
org.osgi.framework.bootdelegation=*
2.
org.osgi.framework.bundle.parent=framework
With the above 2 properties, we make sure that Framework class loader will
be parent of every bundle’s class loader. Core river classes will be
available to all bundles. So there will not be any problems when we
serialize/deserialize any of the river classes.
1.
As there is no downloaded code in this service implementation, we didn’t
require class annotation. So service provider will not face any problems in
the serialization of api and river classes. Service provider export the
service from osgi bundle and register the proxy object without any problem.
2.
But this is not the case at client side. we have a problem in
deserialization of the proxy object. Because we don’t know which osgi
bundle has the service API classes for this proxy. I observed that
PreferredClassProvider is already searching classes from the context
classloader. So if we set the correct context classloader, this will not be
a problem at client side.
3.
So I created a model where osgi bundles can request network service by
registering ServiceTemplate object in osgi registry. As i mentioned in the
previous mail, I created ServiceTemplateTracker which tracks these objects
and remembers the bundle which has requested the network service. it
manages river service discovery process using ServiceDiscoveryManager and
LookupCache. In order to set the context classloader with correct bundle
classloader, I patched the following classes.
1.
BasicInvocationDispatcher
2.
ServiceDiscoveryManager
This solved the deserialization of the proxy at client side.
I'll describe the second type of service in the next mail.
Thanks & Regards,
Bharath
On Mon, Jan 23, 2017 at 5:30 AM, "Michał Kłeczek (XPro Sp. z o. o.)" <
michal.klec...@xpro.biz> wrote:
> Hi,
>
> comments below.
>
> Niclas Hedhman wrote:
>
> On Mon, Jan 23, 2017 at 1:48 AM, "Michał Kłeczek (XPro Sp. z o. o.)"
> <michal.klec...@xpro.biz> wrote:
>
>
> I would say fully declarative approach in OSGI would be to only annotate
>
> with a package version range (and let the OSGI container do the resolution
> - it is designed to do it efficiently).
>
> Of course then we have a problem with classes that are not from any
>
> exported package but from internal bundle class path - then bundle id and
> version might be necessary.
>
> Then of course there is a question of classes from fragment bundles -
>
> this is totally unsolvable since AFAIK there is no way to get the fragment
> information based on the class loader of a class.
>
> Not that I grasp why it is needed, but you can get the Bundle information
> from the classloader, IF the class was loaded by OSGi. OSGi defines
> BundleClassLoader, so you simply cast the classloader to that, and with
> that you can get the Bundle and the BundleContext, which together should be
> able to give you all the meta info that you could need.
>
>
> It is needed to properly annotate a class during serialization.
> AFAIK in OSGI you can not find out which fragment (if any) was used to
> load a class.
> Based on the class loader you can get the bundle, but not the fragment.
>
> The concept of "download the proxy, both code and state" was quite novel
> in 1999 when I first heard of Jini. But I think it should be recognized
> that it both introduces a lot of security problems as well as not being the
> only way this can be done. For instance, the proxy could be an HTML page,
> which downloads JavaScript which binds into a sandbox provided. I think
> that the "serialized object" should not be a requirement eventually, and
> with that removed, the OSGi environment can help quite considerably aiding
> the dynamic nature of River.
>
> My view is different:
>
> 1. Without this "serialized object" approach there is no such a thing as
> River since there is nothing interesting and novel left.
> 2. Indeed - the "serialized object" approach is not popular... But my take
> on this is that it is because the concept has not been implemented
> correctly - both in terms of security and in terms of class loading.
>
> As Peter observed, Pax URL allows a whole bunch of URL schemes, which you
> could be annotated in the serialized objects, just like URL codebases are
> today. For instance, Maven "coordinates" could be in the annotations and
> OSGi loads bundles on-demand. Paremus also implemented a "bundle garbage
> collector" in some manner, which unloaded unused bundles eventually.
> Furthermore, there are defined hooks in OSGi for the resolution of service
> registration and service lookup, which I think River should exploit. There
> seems to be a huge complementary intersection right there.
>
> There are no hooks for _class_ resolution - that's what is needed.
>
> The use case and the ultimate test to implement is simple - have a
>
> listener that publishes remote events to a JavaSpace acquired dynamically
> from a lookup service:
>
> class SpacePublisher implements RemoteEventListener, Serializable {
> private final JavaSpace space;
> public void notify(RemoteEvent evt) {
> space.write(createEntry(evt), ...);
> }
> }
>
> It is NOT possible to do currently. It requires non-hierarchical class
>
> loading. It is not easy to solve. It would open a whole lot of
> possibilities.
>
> I am probably too ignorant to see it; What exactly is "NOT possible" with
> the above use-case snippet?
>
> With currently implemented PreferredClassProvider it is not possible to
> deserialize such an object graph.
>
> Thanks,
> Michal
>
