The use case is actually rather simple, consider a general purpose RMI-implementation. If an RMI-proxy object (created by the RMI-bundle, and an invocation handler from that bundle) is called, all parameters are serialized (so far so good), passed over the wire to the remote JVM, where the parameters are deserialized and passed on to the 'actual' implementation. Now, I must use the classloader from the bundle which issued the call, as the parameters are instances of classes which (in general) are only known to that bundle (I am assuming at this point that the remote server has an equivalent bundle available, that is a separate issue).
Greetings, Fredrik. On Wed, Sep 24, 2008 at 10:51, Niclas Hedhman <[EMAIL PROTECTED]> wrote: > > > On Wed, Sep 24, 2008 at 4:32 PM, Fredrik Alströmer <[EMAIL PROTECTED]> wrote: >> >> 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. > > I think it depends on your use-case. In our cases, the bundle that asks for > the deserializing of the stream passes its classloader to the deserializer > (in our case a service in another bundle). So, I think the following > happens; > > ClassA[CL1] --uses--> ClassB[CL2] --uses--> ClassC[CL3] > > CLx = different bundle classloaders. > > The Bundle for ClassA has a direct visibility to ClassB and must therefor > import ClassB. And during deserialization, the CL1 is passed to the > deserializer, and upon cl1.loadClass() it will delegate to the CL2 for > loading ClassB, which in turn is importing the bundle of CL3 and delegation > happens again. > > I have not had use-cases where random classes are deserialized > "on-demand"... > > > Cheers > Niclas > > > _______________________________________________ > 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
