A good suggestion Isuru! I think the best option is to move the registry based data store to a database due to many reasons. Jane started this effort sometime back but it was halted.
Thanks On Tue, Nov 24, 2015 at 3:35 PM, Isuru Haththotuwa <isu...@apache.org> wrote: > Hi Devs, > > We are heavily using serialization to store context/runtime data > throughout Stratos, and we depend on the default serialization mechanism > provided by Java. The downside of this is if a Serialized class is changed > (adding/removing a non-transient and non-static class variables), we cannot > use any data serialized with the older version of the same class. The only > option in this case is to start with a new deployment of Stratos. > > Currently since we are using the default serialization/deserialization > capabilities by implementing Java Serializable interface, we have no > control over this process. But, if we implement Externalizable [1] > interface, we actually can have some control over the > serialization/deserialization. With this, its the responsibility of the > implementing class to maintain the serialization/deserialization logic. > > To maintain the backward compatibility of serialized data, AFAIU we can do > the following: > > - Maintain a version for serialized classes (ex.: > CloudControllerContext - version 4.1.4) > - Write our own serialization/deserialization logic, depending on the > version > - If a change occurs to the class such that previously deserialized > data can not be used (adding a non-transient member to the class, etc.), > increment the version of the relevant class and modify the deserialization > logic as shown in [2] > > Therefore, even in there is a change to the class signature, still the > already serialized data can be de-serialized from the previous version. I > did a quick PoC for custom serialization and deserialization using > CloudControllerContext class, which worked fine. > > There are few downsides of this approach though: > > 1. Maintain our own serialization/deserialization logic, requires > updating if a change occurs in the relevant classes > 2. The Externalizable interface requires a default non argument > Constructor to work, and that will require some design changes (since we > have private/non-default constructors in a few singleton Context classes) > > wdyt? > > [1]. https://docs.oracle.com/javase/7/docs/api/java/io/Externalizable.html > > [2]. > if ("4.1.4".equals(CC_CONTEXT_VERSION)) { > // de-serialize members in 4.1.4 version > } else if ("4.1.5".equals(CC_CONTEXT_VERSION)) { > // de-serialize members in 4.1.5 version > } > > > -- > Thanks and Regards, > > Isuru H. > +94 716 358 048* <http://wso2.com/>* > > > -- Imesh Gunaratne Senior Technical Lead, WSO2 Committer & PMC Member, Apache Stratos
