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