Equinox has "buddy class loading" to help with these kinds of issues.
I know several people who have used this approach successfully to deal
with RMI
http://wiki.eclipse.org/index.php/Context_Class_Loader_Enhancements
Jeff
Serguey Asael Shinder wrote:
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
|
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
