The repackage broke those two methods. The oldPackage needs to replace "org.apache" with "com.gemstone". It allows interaction with a locator from WAN sites and clients running GemFire.

I'll fix that problem.

Le 9/20/2016 à 11:53 AM, Kirk Lund a écrit :
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
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 = "";
     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 = "
     String newPackage = "

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