Christopher Brown wrote > Hello, > > I need to define an API for an OSGi service capable of persisting arbitrary > Serializable objects as byte arrays (to disk, or over the network), and > then capable of deserializing the object via the API. The objects to be > persisted will almost always be defined by another bundle, so the bundle > actually performing the serialization is almost always going to be unable > to access the classloader that originally provided the definition of the > serialized class (and any non-primitive attributes of that class). > > Any ideas upon how to use java.io.ObjectInputStream such that its > .readObject() method can be forced to use an appropriate classloader? I > can't see how to override its default behavior. > > As for the API I need to implement (my service), it would be along the > lines of: > > void service.store(String id, Object value); > > <T> T service.fetch(String id, Class<T> implementationType) > > ...where implementationType would need to be equivalent to value.getClass() > (and not a superclass or implemented interface). The "fetch" method would > need the "implementationType" parameter to access the CURRENT version of > the classloader (I can't store the classloader in the "store" method, first > off because I can't serialize arbitrary classloaders -- via > value.getClass().getClassloader() -- and also because the classloader might > be the wrong version, if "value" was defined by a bundle that has since > been reloaded). > > Even if I replaced the "implementationType" parameter with a classloader > reference (assuming the caller of the code knew which classloader to use), > I still don't know how to override ObjectInputStream's default classloading > behavior. > > Any ideas ? > You can create a subclass of ObjectInputStream and overwrite the resolveClass method to solve the first project.
Some time ago we wrote some code, that was using a dynamic class loader in such a subclass that simply used Package Admin to find the bundle providing the class and then using the corresponding class loader. Of course this requires that the classes you want to load are publicly exported. I'm not saying this is the best solution, but it did the trick for us. Regards Carsten -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
