Believe me, I'm all in favor of doing stuff the OSGi way.. :) I got my answer already (I realized I didn't need a class loader, I could just make the incision a little bit earlier), but out of curiosity, how do you deal with the case where neither the caller nor the callee has imported the concrete type of the object (both referring to it through interfaces), serialization still works, as the object does have a reference to its concrete class, deserialization on the other hand, not so much.
And could you please elaborate a bit? Maybe I get a little bit confused by your use of "proxy", I mean calling a method on proxy object, forwarding that call, executing it on the server, and transporting the return value back to client, that I understand. I don't get where the proxy bundle comes into play though. What use is a proxy bundle on the client? Or are you talking about distributing the necessary classes to interact with the proxy object? Thanks, Fredrik. On Wed, Sep 24, 2008 at 11:40, Rellermeyer Jan Simon <[EMAIL PROTECTED]> wrote: > Hi Fredrik, > >> I've seen some stuff in the direction of distributed OSGi, however, >> before I delve deep into the implementation details of these, I have >> one question regarding deserialization (which is usually necessary >> when dealing with Java RMI calls). How would I go about doing it, >> normally I would grab the appropriate classloader, and deserialize the >> object graph using that. In OSGi however, there's no way (at least as >> of R4 4.1) to access the classloader of a bundle directly (which makes >> a lot of sense, I'm not questioning that), so how would you go about >> resolving this issue? The best solution I've come up with so far is to >> implement a classloader, mapping methods such as findClass to the >> bundles loadClass etc. There are some semantic differences (primarily >> regarding resolving classes), but I've not been able to construct a >> case where the behavior is undefined or wrong with respect to >> deserialization. >> >> Has anyone else got a better idea, or some other suggestions? > > In R-OSGi [1], I am dealing with serialization by building proxy bundles > rather than proxy objects. I then inject the types referenced by the remote > service into the proxy bundle if they came from the original bundle and map > the imports if they were imported. Thereby, the proxy bundle represents > exactly the part of the original bundle that is reachable through the service > and the deserialization takes the same path on the client that it took when > loaded on the server. So the answer is: Do it the OSGi way and don't try to > use mechanisms that expect a flat classloader hierarchy. > > Cheers, > > Jan. > > [1] http://r-osgi.sourceforge.net > > ------------------------------------------------------------ > MSc Jan S. Rellermeyer, Systems Group, Department of Computer Science, ETH > Zurich > IFW B 47.1, Haldeneggsteig 4, CH-8092 Zürich, Switzerland > http://www.systems.ethz.ch > ------------------------------------------------------------ > > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev > _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
