On Thursday 15 January 2004 16:20, Timothy Bennett wrote: > Does merlin not like serialized objects across composite block boundaries?
Welcome to the World of Serialization!!! Since I happen to have worked a lot with RMI ( http://jcp.org/en/jsr/detail?id=78 ), it is easy(!) to see what is going on. When the byte array arrives at its destination and the ObjectInputStream tries to deserialize the object, it will need the actual class(es) that constitutes this object. The bad news is that the destination's classloader can't load those classes (because the JARs that they are in is not in the classloader's scope). The good news is that there might be a solution. Merlin should NOT use ObjectOutputStream/ObjectInputStream for the job, but the MarshalledObject class in RMI instead. This not only converts the object into a byte stream but also picks up the codebases for the classes used, and allows the deserialization to load the classes from their sources. Within the same API this should work flawlessly, since any filesystem referenced JARs will resolve correctly. It should also work between JVM's IF; 1. Merlin's classloaders are using the globally reachable JARs. This is not the case for repository styled classloader declarations, since Merlin will download them first into the local cache, so for that to work... 2. ... the Merlin repository cache is located in the same directory on both machines. The REALLY nice thing with MarshalledObject, compared to directly using ObjectXXStream is that IF any locally referenced objects implements java.rmi.Remote, MarshalledObject will replace those with the serialized RemoteStubs, which in turn means that the client will invoke remote calls on those objects referenced. MAYBE, this is too much of advanced RMI specific details for Avalon users to consume... but what the hell... I can't explain it better. Cheers Niclas --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
