Deserialization is indeed an issue with OSGi. There is no standard catch-all solution which I am aware of.
If you control the serialization/deserialization process, you can implement solutions like the previous poster mentioned. This doesn't help in cases like Wicket though, where the serialization is done behind the scenes. If you think about it at the conceptual level, serialization kind of runs counter to the dynamic nature of OSGi (although it's a necessary evil in many cases, like Wicket). When you serialize an object, there is no guarantee that the bundle containing the implementation of that object will even be available when you deserialize it. Or, perhaps the implementation of that service has been replaced with a different implementation, which most likely has an incompatible implementation (at least at the object serialization level). On Tue, Dec 1, 2009 at 12:44 PM, Ziegenlippe <[email protected]>wrote: > Hello, > > I cannot find a satisfying solution to a simple looking problem for quite a > while. > > The condensation of the problem: > Bundle A > the producer stores objects as xml files (e.g. with XStream) > it exports the /bundle.a/ package which contains the interface /Item/ it > contains a private implementation package /bundle.a.impl/ which contains the > item implementation class /ItemImpl/ > > Bundle B > the consumer needs to load and process /Item/ instances > therefor it imports package /bundle.a/ which contains the /Item/ interface > > Problem: loading Item instances in bundle B leads always to > ClassNotFoundExceptions > > Even working with the last resort /DynamicImport-Package: * / does not > solve the problem since it imports only exported packages. > > From some hints in the internet I got the feeling that this issue is not > really solved for OSGI. Is there any solution known? How deal others with > that issue e.g. ActiveMq which claims to be OSGI compliant. > Or am I just on the wrong way? > > Thank you in advance, > Andy > >
