Actually this will probably not be enough. That is because bundle B1, which contains the service interface S1, will have been loaded by the OSGi framework running on device D1.
The OSGi framework does not use a classloader that is a subclass of URLClassLoader. So serialized object instances will be sent over the wire to device D2 *without* a URL annotation, that would be used by RMI running on device D2 to download and load classes dynamically. So you will get a RemoteException when doing the remote call, whose underlying cause will be a ClassNotFoundException. This is a known issue of OSGi, which does not have a commonly agreed-upon solution AFAIK. You may want to have a look at the GPL project Newton : http://newton.codecauldron.org/ for a heavily engineered solution (including a rewrite of RMI). Alternatively, if your application allows it, you can tweak the generation of annotations by RMI, through the use of a custom RMIClassLoaderSpi. This is what I have done for SmartFrog (www.smartfrog.org) last summer ; also, people at OPS4J did something similar but that didn't quite work for me. It's called Pax Remoting and might not be very well documented but somebody on this list first told me about it so you should be able to learn more. http://wiki.ops4j.org/confluence/display/ops4j/Pax Hope that helps, -- Olivier Pernet We are the knights who say echo '16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D4D465452snlbxq'|dc _______________________________________________ OSGi Developer Mail List [email protected] http://www2.osgi.org/mailman/listinfo/osgi-dev
