Guard against classloading exceptions with duplicate class names

[guusdk]

Plugins that define the same class name (i.e. package and class name) will have a problem if they try to send that class through the cluster. Hazelcast will deserialize the class and will use the first class definition found in the list of plugins.

The sequence of search for this class loader is first check the hazelcast plugin that includes checking the Openfire core. If not found then try with the other plugins.

A mechanism should be provided that can be used to ensure that the correct classloader is used.

[guusdk]

@GregDThomas described this issue to me like this:

Scenario; you have two plugins, plugin-a and plugin-b.

plugin-b puts an object, of type "com.example.MySpecialClass" in a cache on Node 1
Node 2 attempts to deserialize that object. The first thing it does is find the plugin classloader for that plugin. So it loops through all the plugin classloaders, and finds the first one it can with "com.example.MySpecialClass". However, it turns out plugin-a also has a copy of the very same class, and is found first. The bytes are deserialized to an object, but with a class in the plugin-a classloader. So when plugin-b attempts to access it, you get a class cast exception:
com.example.MySpecialClass (implicitly plugin-a classloader) cannot be cast to com.example.MySpecialClass (implicitly plugin-b classloader)

This is sort-of documented in org.jivesoftware.openfire.plugin.util.cache.ClusterClassLoader which has the offending code in org.jivesoftware.openfire.plugin.util.cache.ClusterClassLoader#loadClass

The workaround is to only use classes that are either unique to a plugin (guaranteeing the correct classloader is used) or classes that are in the main Openfire classloader.

I don't even know if this is possible to fix.Perhaps a custom serializer/deserializer that somehow identifies the plugin to use.

[guusdk]

Work-arounds:

• ensure that class names are unique
• serializing objects (eg: a JSON representation), and storing that in the cache, instead of the original object

[guusdk]

Also discussed in: https://discourse.igniterealtime.org/t/cachefactory-cast-error-in-clustring/