In case you're wondering why I've created bundles / modules
structured like below, if the endpoint was deserialized into the
service implementation bundle instead of the proxy bundle,
it may not be able to see deserialized classes from the proxy bundle's
transitive imports.
In effect the proxy bundle becomes the equivalent of the application
ClassLoader at each endpoint.
So any annotated classes will be loaded into PreferredClassLoader's
that have the proxy bundle as the parent ClassLoader. Any classes in
these ClassLoaders would have a very limited view, they could only
utilise packages imported by the proxy bundle, allowing the proxy
to limit available classes very easily, similar to a sandbox.
For example Mercury's proxy would allow packages in the java.* namespace
plus classes from any of the following packages:
Import-Package: net.jini.admin;version="[3.0,4)",net.jini.core.constra
int;version="[3.0,4)",net.jini.core.discovery;version="[3.0,4)",net.j
ini.core.entry;version="[3.0,4)",net.jini.core.event;version="[3.0,4)
",net.jini.core.lease;version="[3.0,4)",net.jini.event;version="[3.0,
4)",net.jini.export;version="[3.0,4)",net.jini.id;version="[3.0,4)",n
et.jini.io;version="[3.0,4)",net.jini.lookup;version="[3.0,4)",net.ji
ni.security;version="[3.0,4)",net.jini.security.proxytrust;version="[
3.0,4)",org.apache.river.admin;version="[3.0,4)",org.apache.river.api
.io;version="[3.0,4)",org.apache.river.landlord;version="[3.0,4)",org
.apache.river.proxy;version="[3.0,4)"
DownloadPermission can be used to prevent marshalling of downloaded
objects.
However the service could advertise available resouces via an Entry.
Cheers,
Peter.
On 23/02/2017 4:13 PM, Peter wrote:
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.
