Guido Spadotto wrote: > Another guy claimed he solved this issue [1], but I won't believe until > I see it running. > > ... > [1]: > http://archive.timeindexing.codehaus.org/lists/org.codehaus.xstream.user/msg/19183331.p...@talk.nabble.com >
On second though I think this wrapper function should work even if you assemble object graphs from classes exported by many bundles. As soon as you give XStream a Class object to start from it does not need any special class loading magic. It only needs the (always available) reflection API to traverse bundle class spaces. It can touch private classes and create empty instances too - as long as it uses reflection to do so. Often even that wrapper function is too complicated. The class you deserialize is likely imported in the local bundle because you usually do an explicit cast: Person newJoe = (Person) xstream.fromXML(xml); So in most "normal" usecases the solution I proposed first should work - pass in the local ClassLoader. Or to be safer use the wrapper - it will force you to provide a Class object which in most cases will be a type literal: Person newJoe = (Person) xstream.readClass(xml, Person.class); //Bit Redundant On the other hand if you want to have a bundle that deserializes types it never "sees" (e.g. it treats the results as Object) and do not want to worry about providing a Class object the dynamic bridge will work better. The bridge becomes risky when there are multiple versions of the same package within the OSGi container. This is because it uses the PackageAdmin service to map String names to exporter bundles. In a multi version situation however PackageAdmin.getExportedPackage() will always return the highest version of the package. But what if you pass the deserialized object to code that was compiled against a lower incompatible version? Bridges are cool but risky: They create a class space that resembles the good old java class path with it's first-see first-pick policy. As we know such a class space does not tolerate multiple versions of the same thing :P Cheers, Todor --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
