When you think about classes with annotations in this environment, it
also means that classes at the client
may not return to the originating ClassLoader as boomerangs, unless
they're resolved by a common imported package by the proxy bundle. When
the boomerang returns it will be loaded in a PreferredClassLoader which
has the proxy as the parent ClassLoader in teh client instead of the
originating ClassLoader.
So if the client registered a listener with a service that remotely
filtered or sent events as batches, the client would have to view the
results via a common api interface. There would of course be no
codebase annotation losses, the point is objects may not return to their
originating loader, so it would seem best to avoid using codebase
annotations in OSGi unless a developer is very familiar with
ClassLoaders etc.
It might be possible to register ClassLoader's with their codebase
annotation locally and associate them with proxy ClassLoaders, via a
lookup list in PreferredClassProvider, allowing boomerangs to return to
the correct ClassLoader, while also allowing PreferredClassProvider to
discover annotations. The annotation itself doesn't need to be a
reference to the Bundle, just a suitable list of jar files that would
provide the same classes.
The thought exercise is interesting in any case. Sometimes though,
simpler is better, it may be preferable to see how developers cope
without the bells and whistles first as this is far easier to debug and
less subject to problems, for some minor sacrifices in capability.
Regards,
Peter.
On 24/02/2017 8:52 AM, Peter wrote:
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.
