synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hubert, Eric" <>
Subject RE: Constant/reproducable order of elements in synapse.xml
Date Sun, 08 Nov 2009 10:22:05 GMT
Hi Supun,

Please see my comments inline!

Synapse language is treated as a programming language at least for the out side world. For
example sequences can be attributed to functions. In any programming language the order in
which these symbols occur does not matter as long as the symbols can be found by the caller.
So I have doubts in implementing an order for the synapse elements. By order I meant something
like all the sequences are at the top then the proxy services etc.
I share these doubts, but you describe exactly the current implementation. Please have a look
at: SynapseXMLConfigurationSerializer.serializeConfiguration(SynapseConfiguration synCfg).
It uses a fixed order of top level elements.
Specific element serializers are then using an order depending on the way the configuration
has been stored in memory. Mostly the XML information will be transferred to strongly typed
data structures. While deserializing those values, currently a fixed order will be used. This
might be different, from the one originally read in. Some list like structures are stored
to unordered Map-Implementations for faster key-value access. While deserializing those values
you end up with a random order. I think that this part could be fixed rather easily by using
LinkedHashMap preserving the key order in which entries have been added to the map.

When a user types in the synapse.xml, we should be able to preserve the order in which they
have entered the elements in the synapse.xml. If you meant this one I'm +1 for implementing
I also agree this would be the most desirable option, although the current implementation
seems to be very far a way from that. Each factory/serializer pair would need to be designed
for this purpose (e.g. keep a list or list of linked maps or any suitable structure of read
elements/attributes, store it for deserialization purposes only and use this to retrieve the
values in the exact order from structured object structures). I guess only something like
this could warrant a working round-trip serialization/deserialization where the user may modify
any part of the configuration, insert new stuff at any allowed place and this exact order
will be preserved during later deserializations.
So my concrete suggestion for a start was just to replace all class member implementations
of SynapseConfiguration which are currently of type HashMap with LinkedHashMap. From my point
of view this is at least an improvement. No pain, big gain? ;-)
View raw message