That Configuration class implements DataSerializable, not PdxSerializable. FYI the PdxReader does have a method to check if a field is present.
The way to handle different versions of geode with DataSerializable is to use the versioning support described on this page - https://cwiki.apache.org/confluence/display/GEODE/Managing+Backward+Compatibility. Essentially, you provide alternate toData_XXX and fromData_XXX methods that control how the object is sent to and received from members withe older versions. BTW the PdxReader does have a method to check if a field is present, but we generally don't use PDX for internal serialization since PDX actually depends on at lot of geode components like regions, WAN, etc. -Dan On Thu, Jan 12, 2017 at 11:54 AM, Anilkumar Gingade <aging...@pivotal.io> wrote: > 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 > >> > >> > > >
