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.
    String newPackage = "org.apache.geode.management.

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?


Reply via email to