Hi, Newton's been mentioned a couple of times in this thread, so I thought I'd write a quick note to clear up what its approach to RMI does and does not do.
Thankfully, we haven't had to reimplement all of RMI. Under the covers all we've done is change the way RMI deals with classloaders and codebases, to make it more OSGi friendly. Also, our RMI work doesn't involve any bytecode manipulation. Our early work made it possible to associate a codebase with a bundle using an new manifest header. Newton's deployment process takes care of making the codebase jars available, so that there's no separate stage in which you have to put jars on an HTTP server etc. We still use this approach, although we are gradually phasing it out. Our current approach is based on bundles only, rather than special codebase jars. In this approach bundle and package integrity are never violated so, for example, it doesn't involve transfer of classes independent of their bundles or dynamic generation of new bundles. Keeping it very brief, we use codebase annotations to encode the identity of the bundle or public package from which each class comes. During deserialization this information is used to decide which classloader to use, and to install any missing bundles. In our view an ideal solution would require a couple of changes to the way OSGi works, so we've outlined the issues as we see them in an RFP submitted to the OSGi EEG. Similar issues apply to other widely used technologies, such as ORM based persistence, so we're hopeful that a future OSGi specification will tackle them. Regards, Robert On 26/11/2007, Niclas Hedhman <[EMAIL PROTECTED]> wrote: > > On Nov 24, 2007 3:00 PM, Olivier Pernet <[EMAIL PROTECTED]> wrote: > > ; also, people at OPS4J did something similar but that didn't quite > > work for me. It's called Pax Remoting and might not be very well > > documented but somebody on this list first told me about it so you > > should be able to learn more. > > http://wiki.ops4j.org/confluence/display/ops4j/Pax > > Pax Remoting is work in progress, and not by any means operational. > After the project started, the need was reformulated. However, I am > still interested in getting this going again, so we can start working > on the OSGi specs in this area, and I think we need a bit more > experience to understand the nuances, like the Paremus guys do. > > > Cheers > Niclas > _______________________________________________ > OSGi Developer Mail List > [email protected] > http://www2.osgi.org/mailman/listinfo/osgi-dev >
_______________________________________________ OSGi Developer Mail List [email protected] http://www2.osgi.org/mailman/listinfo/osgi-dev
