Thanks a lot for your answers. I think we would like to stick to RMI for now, so it looks that dynamic RMI classloading is the only option. But it doesn't seem to be very straightforward though. Serguey
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of ekkehard Sent: 16 December 2008 15:46 To: OSGi Developer Mail List Subject: Re: [osgi-dev] RMI + OSGi - UnmarshalException you can also look at Eclipse Riena Remote OSGI Services ekke David Bosschaert schrieb: > Hi Serguey, > > One thing that might help you here is using an implementation of the > Distributed OSGi specification (RFC 119 in > http://www.osgi.org/download/osgi-4.2-early-draft2.pdf ) This allows > you to distribute OSGi services. > > RFC 119 isn't completely finalized yet and at this stage there isn't a > fully complete implementation yet, but you can start playing with the > Reference Implementation in Apache CXF. Currently in the sandbox - > were working on making it part of the core code base and improving the > docs at the moment. > > To build & test, just check it out from SVN > http://svn.apache.org/repos/asf/cxf/sandbox/dosgi > Then run > mvn install > > Cheers, > > David > > Niclas Hedhman wrote: >> 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 >> >> > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
