On Tue, Dec 16, 2008 at 8:27 PM, Serguey Asael Shinder <[email protected]> wrote:
> This is from February of this year, does anyone know what the latest on this > issue is? Do you have any suggestions as to how we can get around this > issue? We would prefer if possible not to have to put all our classes in the > same bundle. Thanks in advance for your help. 1. Either you turn on dynamic classloading for RMI, with all what that means, or you have all the needed classes visible to the server (which is the case causing you problem here). 2. If you go dynamic RMI classloading -> you need to establish codebase, probably only way is to use java.rmi.server.codebase property, AND you must use a SecurityManager. 3. If you go 'all classes in Bundles', then you have a visibility issue. RMI might not be able to pick up the right classloader (have not confirmed that), in which case you need to use the RMIClassLoaderSpi to provide the mechanism manually. This is 'classloader hell' on an extreme. Both OSGi and RMI assume that they know classloading better than the other, so they end up being largely incompatible. And we programmers have no clue what is going on, because we have been so lazy over the years to use a flat/linear classloading space. Personally, I think it is time for a new, optimized, simplified binary and high performant Remote call system, where all these things are taken care of. But, everyone is busy criticizing RMI and promote so called "platform independent" solutions, that have all these problems, much slower, LCD issues and more... Well... Cheers Niclas _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
