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.
OK. I think this is better than the option below.
Alternatively, the GBeanInfo for the Configuration could also be serialized, or the constructed GBeanInfo could put the attributes in a SortedSet.
---------------- Other unimplemented features in the configuration code are -endpoint patterns are not serialized
Oops
-stop does not in fact serialize the configuration.I added the comment but was not sure we actually wanted to do this. I am torn between automatically saving the state on stop and having an explicit method on the Configuration that saves the state; the first is easy, the second gives the admins more control.
Any thoughts?
thanks david jencks
