Return-Path: Delivered-To: apmail-synapse-dev-archive@www.apache.org Received: (qmail 20188 invoked from network); 9 Nov 2009 04:46:23 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 9 Nov 2009 04:46:23 -0000 Received: (qmail 5695 invoked by uid 500); 9 Nov 2009 04:46:23 -0000 Delivered-To: apmail-synapse-dev-archive@synapse.apache.org Received: (qmail 5509 invoked by uid 500); 9 Nov 2009 04:46:21 -0000 Mailing-List: contact dev-help@synapse.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@synapse.apache.org Delivered-To: mailing list dev@synapse.apache.org Received: (qmail 5501 invoked by uid 99); 9 Nov 2009 04:46:20 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 09 Nov 2009 04:46:20 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of supun06@gmail.com designates 209.85.216.176 as permitted sender) Received: from [209.85.216.176] (HELO mail-px0-f176.google.com) (209.85.216.176) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 09 Nov 2009 04:46:10 +0000 Received: by pxi6 with SMTP id 6so1271020pxi.0 for ; Sun, 08 Nov 2009 20:45:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=yeJHBuRKScjSUi3P68eZm2asW7bODX2JRB84R8N9yec=; b=IF+4YY7fJP8ysU8C1i8t1KZv6IdzmnXDNQ3tDONjJhE5it4Jrb+UCKs1DwvHnce5DR lv2t6w5cIDp9dtTI8+uSfXgrt+q8FMqMEPKpk5KvCIlrDcWDk0HLriFt3F206E1hLMzD xzOPXdMAzSXuolGO2UuE++3nCsYooYtqM7QcI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=SuVx4EPrQZV7hcxbDJYNMU/V8qkUnET9dv6C7/k7qe6szwPC/zC+FfFS0doM97ZMaE XM6LXHPMPpU//Hrx5j28vbIQafVoUPfUoOfDgXMGa+zV1Uip7swYX2eLghS3pAxeNcR0 SiC3WNsSuhDBrTOCKJOENTmlat1vUfvkKe2kc= MIME-Version: 1.0 Received: by 10.142.7.3 with SMTP id 3mr734687wfg.126.1257741949110; Sun, 08 Nov 2009 20:45:49 -0800 (PST) In-Reply-To: References: Date: Sun, 8 Nov 2009 20:45:49 -0800 Message-ID: Subject: Re: Constant/reproducable order of elements in synapse.xml From: Supun Kamburugamuva To: dev@synapse.apache.org Content-Type: multipart/alternative; boundary=00504502b0891888d80477e8de6c X-Virus-Checked: Checked by ClamAV on apache.org --00504502b0891888d80477e8de6c Content-Type: text/plain; charset=ISO-8859-1 Hi Eric, I thought about this a bit further. Synapse runs on an object model. Not on a XML configuration. As far as I understood this was the original goal. Also it makes sense. The synapse configuration can be created using XML or may be spring or may be pure programming. At the synapse object model layer I think it is logical to use a hash map. If a particular serialization and building wants to have an order it is the responsibility of the build and serialize method writer to impose it. Isn't there a way to impose this at the serialize and builder level? Thanks, Supun.. On Sun, Nov 8, 2009 at 2:22 AM, Hubert, Eric wrote: > 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. > > Agreed. > > 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 it. > 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? ;-) > > Regards, > Eric > -- Software Engineer, WSO2 Inc http://wso2.org supunk.blogspot.com --00504502b0891888d80477e8de6c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Eric,

I thought about this a bit further. Synapse runs on an obj= ect model. Not on a XML configuration. As far as I understood this was the = original goal. Also it makes sense. The synapse configuration can be create= d using XML or may be spring or may be pure programming. At the synapse obj= ect model layer I think it is logical to use a hash map. If a particular se= rialization and building wants to have an order it is the responsibility of= the build and serialize method writer to impose it.

Isn't there a way to impose this at the serialize and builder level= ?

Thanks,
Supun..

On Sun, Nov 8= , 2009 at 2:22 AM, Hubert, Eric <Eric.Hubert@foxmobile.com> wrote:

Hi Supun,

=A0

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.

Agreed.

So I h= ave 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 servic= es etc.

I share these doubts, but you describ= e exactly the current implementation. Please have a look at: SynapseXMLConfigurationSerializer.se= rializeConfiguration(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 informa= tion 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 deserializ= ing those values you end up with a random order. I think that this part could b= e fixed rather easily by using LinkedHashMap preserving the key order in which entr= ies have been added to the map.



When a user types in the synapse.xml, we should be able to preserve the ord= er in which they have entered the elements in the synapse.xml. If you meant th= is one I'm +1 for implementing it.
I also ag= ree 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 t= his 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 thi= s to retrieve the values in the exact order from structured object structures). = I guess only something like this could warrant a working round-trip serializa= tion/deserialization where the user may modify any part of the configuration, insert new stuff a= t any allowed place and this exact order will be preserved during later deserializations.

So my concrete suggestion for a start was j= ust 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? ;-)

Regards,
=A0=A0=A0 Eric




--
Software Engineer, WSO2= Inc
http://wso2.org
supunk.blogspot.com


--00504502b0891888d80477e8de6c--