And, of course, there's Newton... which is more than just "ipc", but also load balancing and "composite level services"...
________________________________ From: [email protected] on behalf of Jeff McAffer Sent: Tue 12/16/2008 10:12 AM To: OSGi Developer Mail List Subject: Re: [osgi-dev] RMI + OSGi - UnmarshalException You might also look at the Eclipse Communications Framework (ECF) project (http://eclipse.org/ecf) which has a number of distributed/remote communications facilities for OSGi. An RFC119 implementation should show up there soon too. Jeff David Bosschaert wrote: > 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 </div> _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
<<winmail.dat>>
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
