geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: Problem with configuration serialization code
Date Wed, 14 Jan 2004 01:22:02 GMT
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 ;)


View raw message