If current develop attempts to read a cluster config that was persisted
prior to the repackage, our code now throws ClassNotFoundException. Turns
out Cluster Config is implemented by the
class org.apache.geode.management.internal.configuration.domain.Configuration
which is a DataSerializable. Unfortunately, a DataSerializableFixedID was
never added for this class, so the code resorts to using the fully
qualified class name.
While brainstorming possible workarounds, we noticed a jgroups related
method in DataSerializer called swizzleClassNameForRead which is called
from readObject(DataInput):
/**
* For backward compatibility we must swizzle the package of
* some classes that had to be moved when GemFire was open-
* sourced. This preserves backward-compatibility.
*
* @param name the fully qualified class name
* @return the name of the class in this implementation
*/
private static String swizzleClassNameForRead(String name) {
String oldPackage = "org.apache.org.jgroups.stack.tcpserver";
String newPackage = "org.apache.geode.distributed.internal.tcpserver";
String result = name;
if (name.startsWith(oldPackage)) {
result = newPackage + name.substring(oldPackage.length());
}
return result;
}
The package in red above never existed. I now have two questions: a) did
the repackage break this so that JGroups now need two swizzles (one for the
jgroups upgrade and now a 2nd for the apache repackage)? b) can cluster
Configuration piggy back on this technique for handling the serialized
Configuration for cluster config?
1) jgroups upgrade
String oldPackage = "com.gemstone.jgroups.stack.tcpserver";
String newPackage = "org.apache.geode.distributed.internal.tcpserver";
2) apache repackage for jgroups
String oldPackage = "com.gemstone.gemfire.distributed.internal.tcpserver
";
String newPackage = "org.apache.geode.distributed.internal.tcpserver";
3) apache repackage for cluster config
String oldPackage = "com.gemstone.gemfire.management.internal.
configuration.domain";
String newPackage = "org.apache.geode.management.
internal.configuration.domain";
Can anyone else think of something similar that might be broken? We could
scan the source code for DataSerializables that don't have a
corresponding DataSerializableFixedID.
Should we also scan for Serializable classes and try to determine if they
might be similarly persisted in a way that might break a feature?
Is this the best way to handle this? Should we reorganize
swizzleClassNameForRead to be a series of registered DataSwizzlers?
Thanks,
Kirk
