Dear Wiki user, You have subscribed to a wiki page or wiki category on "River Wiki" for change notification.
The "Serialization" page has been changed by PeterFirmstone: http://wiki.apache.org/river/Serialization?action=diff&rev1=12&rev2=13 The examples here are relatively simplistic, it is possible to have a number of Serialization Builder implementation classes. It is also likely that the static factory method Builder.new() might accept parameters or may choose different builder implementations under different conditions. - You could also for instance have two serialized forms, one old, one new. A configuration setting could dictate the use of only the old serialized form until your environment has been completely upgraded, then set the configuration to only use the new serialized forms. Any old marhsalled objects (in serial form) will still be able to be deserialized, but no more in this form will be created, so will eventually disapear. + You could also for instance have two serialized forms, one old, one new. A configuration setting could dictate the use of only the old serialized form until your environment has been completely upgraded, then set the configuration to only use the new serialized forms. Any old marshalled objects (in serial form) can still be deserialized, but no more created in the old form and will eventually disapear. The Serializable Builder pattern is inspired by the Serializable Proxy pattern[1], where the proxy has been decoupled using an abstract builder.
