All this talk of serialisation has led me to think how it should be done in a true OSGi way, and I wound up concluding basically this.
Firstly, that the serialise/deserialise implementations for a given class should be registered from the same bundle that uses the class, or at the very least some separate bundle which only depends on that bundle, so that it's easier to swap out the bundle and its serialisation logic at the same time. Secondly, that what the serialiser should be putting into the stream is the name of the interface rather than the name of their implementation class, otherwise you defeat the purpose of OSGi by depending on a specific implementation when you load it back in. And as Mike Haney was suggesting earlier in the thread, the bundle which implemented the interface might not exist when you read it back in, so whatever performs the over deserialisation would need to take that into account and leave in some kind of stub object which can hang around in the model while the real implementation isn't loaded. I think you would have to take account of the reverse as well. The model might be built while a bundle was loaded, and then the bundle might be unloaded -- yet you would expect serialising the model to still work as expected. All of this seems feasible if you're implementing an alternative to Object(Input|Output)Stream, but what if you want to use an ODBMS? I imagine this would make things very difficult indeed. TX --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
