Sent from my Samsung device. Include original message ---- Original message ---- From: Peter <j...@zeus.net.au> Sent: 23/02/2017 03:26:15 pm To: dev@river.apache.org <dev@river.apache.org> Subject: OSGi Bundles for services
I've attached some ASCII of the relationship between server and client jvm bundles. The ClassLoader at the server is set using the invocation layer factory (a configuration item). The client ClassLoader is determined during delayed unmarshalling and smart proxy bundle provisioning. This ensures that deserialization at each endpoint has a compatible view of classes (as recently discussed on osgi-dev). It's important at this time to distinguish between remote objects and remote services, registered with a lookup service. A remote service must have a proxy bundle for OSGi. The proxy bundle manifest determines requirements and wiring to package import versions. This includes dynamic proxy based services. For arguments sake, a remote object becomes a remote service when it is registered with a lookup service. A remote object isn't registered with a lookup service. Listeners are typically remote objects. In OSGi, it is advisable for remote objects to be dynamic proxy's without a codebase. Remote Object proxy's will be deserialized into the remote endpoint's nominated ClassLoader. For example, if it is transferred via a service, the remote object's dynamic proxy stub will be loaded into the service's proxy bundle ClassLoader in the server jvm. As Nic pointed out earlier, Bundle ClassLoader's are not instances of URLClassLoader and lack codebase annotations as a result. With the above rules in place, there is no need to create a custom RMIClassLoaderSpi specific to OSGi. With the above rules in place, it does open up an opportunity to use a remote object (eg a listener) with a conventional codebase as Mic had requested. This would use the PreferredClassProvider infrastructure, so the remote object proxy PreferredClassLoader would utilise the services server jvm proxy bundle ClassLoader as it's parent. This style of remote object should not be registered as a remote service. I would probably discourage this use case, except for advanced users. I think we need to make a distinction between remote services and remote objects for OSGi. This is a very practical solution for OSGi. Regards, Peter. Sent from my Samsung device.
