On Jan 13, 2004, at 5:31 PM, David Jencks wrote:
I think there is a problem with the new configuration serialization code. It appears to rely on the ordering from a set iterator.
Configuration constructs it's GBeanInfo in some static code. This GBeanInfo is not serialized with the other contents of a configuration. However the persistent attributes are written out in the order presented by a HashSet iterator on the source machine. When it is read back in, the local machines GBeanInfo is used, in particular the order of persistent attributes is determined by a HashSet iterator on this local machine. There is no reason to suppose the ordering will be the same for 2 different machines.
This is not a problem for subsequent GBeanInfo objects in the configuration, since the ordering of persistent attributes is serialized in the GBeanInfo, which is deserialized on the target machine before reading the attribute values.
However, I think that depending on the ordering being serialized/deserialized is obscure and risky. I would prefer to see the list of persistent attributes become computed on demand or transient, and the persistent attributes stored with their names.
Sounds much better to me, but Jeremy wrote this. He should be back online tomorrow (or tonight if he is a major geek).
Alternatively, the GBeanInfo for the Configuration could also be serialized, or the constructed GBeanInfo could put the attributes in a SortedSet.
I like the first one better, should be more efficient on disk also.
---------------- Other unimplemented features in the configuration code are -endpoint patterns are not serialized -stop does not in fact serialize the configuration.
Jeremy get to work ;)
-dain
