I propose the following steps to create smart river services in OSGI environment.
Service provider side. 1. Create 4 osgi bundles as described below. All these bundles can import, export packages like regular osgi bundles. 1. Service API - This bundle contains service interfaces and supporting classes. This bundle will be available at both provider and consumer side. 2. Proxy - This osgi bundle depends on service API bundle and imports packages from it. It may import packages from other bundles also. Initially this bundle will be available at service provider side and later downloaded by the consumer. Please note that this bundle will not be deployed in osgi container. 3. Service implementation - depends on service api and proxy bundles. Like reggie, it may use private communication protocol. It imports packages from api and proxy bundles. It may import additional packages from other bundles also. Please note that this bundle will not be deployed in osgi container. 4. Service bootstrap bundle - This bundle wraps proxy bundle jar and service implemetation bundle jar files as resource files. These jar files will not be in the classpath. This bootstrap bundle imports all packages that are required by proxy bundle and service implementation bundles, even though it doesn't use these packages internally. This bundle registers a "ServiceDescriptor" (example NonActivatableServiceDescriptor) service into osgi registry. classpath - URLs of proxy and service implementation jar files which are inside the bootstrap bundle. export codebase - location where user can download the proxy bundle (pax url can be used) impl class - service implementation class policy and configuration can be supplied 2. We can implement a ServiceTracker(OSGI) to track these ServiceDescriptor services. Whenever a ServiceDescriptor is registered into OSGI registry, we can process these descriptors from this ServiceTracker. I observered that NonActivatableServiceDescriptor implementation creates a PreferredClassLoader instance and uses the context classloader as parent. Before calling the ServiceDescriptod's create method, we can set the bundle's class loader as context class loader. So classes that are required for service implementation and proxy jars will be available through bundle class loader. As bootstrap bundle is already importing packages that are required by proxy bundle and service implementation bundle, these classes will be available to preferredClassLoader instance. As PreferredClassLoader implements ClassAnnotation interface, smart proxy instance will be annotated with proxy bundle location. River classes are already available from framework class loader which is parent for all bundles. Modifications required? 1. We can provide some abstraction in river code to create smart services ( codebase, classpath, implementation class name) 2. policy and configuration can be passed via osgi configuration admin service. 3. We need to create a service tracker to track these smart service instances. In the service tracker, we will set the bundle class loader as context class loader before creating the service instance and proxy. In the POC, I have wrapped lookup service(reggie.jar) and dl file(reggie-dl.jar) as regular jar files. Service API classes are already available from river fragment. These api classes will be available from framework class loader. I have also made few modifications with NonActivatableServiceDescriptor. But this is not required. I'll describe about the client side of smart service in the next mail. On Tue, Jan 24, 2017 at 9:08 AM, Gregg Wonderly <ge...@cox.net> wrote: > That’s what I was suggesting. The code works, but only if you put the > required classes into codebases or class paths. It’s not a problem with > mobile code, it’s a problem with resolution of objects in mobile code > references. That’s why I mentioned ObjectSpace Voyager. It automatically > sent/sends class definitions with object graphs to the remote VM. > > Gregg > > > On Jan 23, 2017, at 3:03 PM, Michał Kłeczek (XPro Sp. z o. o.) < > michal.klec...@xpro.biz> wrote: > > > > The problem is that we only support (smart) proxies that reference only > objects of classes from their own code base. > > We do not support cases when a (smart) proxy wraps a (smart) proxy of > another service (annotated with different codebase). > > > > This precludes several scenarios such as for example "dynamic exporters" > - exporters that are actually smart proxies. > > > > Thanks, > > Michal > > > > Gregg Wonderly wrote: > >> I guess I am not sure then what you are trying to show with your > example. > >> > >> Under what case would the SpacePublisher be sent to another VM, and how > is that different from normal SmartProxy deserialization? > >> > >> Gregg > >> > >>> On Jan 23, 2017, at 2:39 PM, Michał Kłeczek (XPro Sp. z o. o.) < > michal.klec...@xpro.biz> <mailto:michal.klec...@xpro.biz> wrote: > >>> > >>> > >>> > >>> Gregg Wonderly wrote: > >>>>> michal.klec...@xpro.biz <mailto:michal.klec...@xpro.biz> <mailto: > michal.klec...@xpro.biz> <mailto:michal.klec...@xpro.biz> <mailto: > michal.klec...@xpro.biz> <mailto:michal.klec...@xpro.biz> <mailto: > michal.klec...@xpro.biz> <mailto:michal.klec...@xpro.biz>> wrote: > >>>>>>> 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. > >>>> This can happen, but what’s necessary is that the codebase of the > SpacePublisher needs to include all the possible RemoteEvent classes, or > the javaspace’s classpath has to include them. > >>> I am not sure I understand. > >>> The problem does not have anything to do with RemoteEvent > (sub)classes. The issue is that SpacePublisher cannot be deserialized at > all ( except one case when JavaSpace interface is available from context > class loader and it is not marked as preferred in SpacePublisher code base). > >>> > >>> Michal > >> > >> > > > >
