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 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.
