One more option would be, by taking advantage of PDX versioning support...The PDX mechanism can handle multiple versions of the same class, instead of modifying the existing field, you could add a new field with Map type....When new locator (with new pdx version) reads the old configuration, it constructs the PDX with older version...
-Anil. On Thu, Jan 12, 2017 at 11:35 AM, Anilkumar Gingade <aging...@pivotal.io> wrote: > Jared, > > I meant the server/product version number, if it was stored as part of the > ClusterConfig definition in the pdx...If its not, we could think about > adding one, which could help in the future to identify the version of the > cluster configuration saved/created. > > -Anil. > > > On Thu, Jan 12, 2017 at 11:18 AM, Jared Stewart <jstew...@pivotal.io> > wrote: > >> Anil - The class does have a serialVersionUID defined, if that’s the type >> of version number you mean. But the serialVersionUID is not explicitly >> written out by the toData() method of the class. Could you point me to any >> examples in the code of checking the version number on a PDX serialized >> instance? >> >> - Jared >> >> > On Jan 12, 2017, at 11:07 AM, Anilkumar Gingade <aging...@pivotal.io> >> wrote: >> > >> > You can use version numbers, if its available... >> > >> > We use this mechanism in many cases, rolling upgrade(?), Server to >> client >> > communication... >> > >> > -Anil. >> > >> > >> > On Thu, Jan 12, 2017 at 10:52 AM, Jared Stewart <jstew...@pivotal.io> >> wrote: >> > >> >> Cluster configuration [1] is currently serialized with PDX and stored >> in >> >> an internal region that is replicated on all Locators. I would like to >> >> change the Configuration class from having a Set<String> jarNames to >> having >> >> a Map<String, byte[]> jarNamesToJarBytes. However, this would create a >> >> problem when a Locator running the new version of the software tries to >> >> deserialize an instance of the previous version of the Configuration >> class. >> >> >> >> Basically, inside Configuration’s fromData() method, I would like to >> >> determine whether the serialized instance came from a version of the >> class >> >> with a Set or a version of the class with a Map. However, I don’t see >> >> methods in DataSerializer to check for the existence of a particular >> field >> >> name or field type. Does anyone know of a strategy that has been used >> in >> >> the past to make these sort of changes? >> >> >> >> Thank you, >> >> Jared >> >> >> >> >> >> [1] org.apache.geode.management.internal.configuration.domain. >> >> Configuration >> >> >
