Re: OSGi Bundles for services
Hmm, ASCII keeps getting scrubbed, so here it is:
SERVER JVM
__
| |
| Service |
| API Bundle |
|__|
|
|
Imports
API
Packages
|
|
__|___
|| Imports packages | |
| Service Bundle |<| Proxy Bundle |---EP
| Implements | from proxy |__| |
| Proxy API||
|||
|
|
|
|
|
N
E
CLIENT JVM T
W
O
__R
| | K
|| Imports packages | Service | |
| Management Agent |<| API Bundle | |
| Discovers & | from API |__| |
| Registers service || |
||| |
Imports|
API |
Packages |
| |
| |
__|___|
| | |
| Proxy Bundle |---EP
|__|
Note other package imports omitted for clarity.
On 23/02/2017 3:26 PM, Peter wrote:
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 ca
Re: OSGi Bundles for services
Sent from my Samsung device. Include original message Original message From: Peter Sent: 23/02/2017 03:26:15 pm To: 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.
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.
