[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[orbit-dev] class loading issue with deserializing commons collections bags


This concerns the already available apache-commons-collections plugin: Any AbstractHashBag subclass (pretty much every Bag implementation) has custom handler methods for serialization and deserialization. When deserializing a Bag with objects from another classloader, this results a ClassNotFoundException, because through these custom handler methods the class loader of the commons-collections-plugin is used instead of the calling classes classloader. There is no way to circumvent this problem with thread context class loaders because java's serialization doesn't use those, which makes it impossible for client code to utilize the Bag implementations from the plugin in combination with serialization.

There is however a rather simple (albeit inconvenient) fix for this: The plugins manifest file can be extended with a line "Eclipse-BuddyPolicy: registered", which would allow other plugins to register as a buddy with the collections plugin, which resolves the class loading issue. As it stands right now, i would have to create my own version of a collections plugin just to add this line into the manifest file. I think it might be a better choice to add the buddy policy to the existing plugin in orbit as i don't think that it can cause any problems otherwise.

Of course the solution is still not ideal because deserializing a bag still wouldn't "just work" (unless maybe "global" instead of "registered" would be used as buddy policy, but that might cause significantly increased performance costs afaik). But it would allow developers to get it to work without having to create their own version of the plugin.

Is it possible to implement this change? Or is there another solution to the issue that i have not found?


[1] http://commons.apache.org/collections/