synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Supun Kamburugamuva <supu...@gmail.com>
Subject Re: Constant/reproducable order of elements in synapse.xml
Date Fri, 06 Nov 2009 19:02:03 GMT
Hi Eric,

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.

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.

Thanks,
Supun..

On Fri, Nov 6, 2009 at 2:32 PM, indika kumara <indika.kuma@gmail.com> wrote:

> Hi Eric
>
> My + 1 for using sorted collection implementations, if it enables to
> serialize synapse XML in a consistent order.
>
> I also prefer to encapsulate all extensible points throughout the code
> base using a single consistent way ... may be factory mechanism.
>
> Thanks
> Indika
>
> On Thu, Nov 5, 2009 at 1:44 PM, Hubert, Eric <Eric.Hubert@foxmobile.com>
> wrote:
> > Hi devs,
> >
> > Currently the implementation of the Synapse configuration model uses
> unordered collections to store the different configuration items (like proxy
> services etc.).
> >
> > Thus serialization creates fixed order of main elements, but changing
> order of items within main elements. Diffing of XML-files created based on
> built-in serialization to track changes on this level is almost impossible.
> >
> > Would somebody object to using sorted collection implementations instead?
> >
> > Background: We are currently using a custom mechanism to create a synapse
> XML Configuration file. This mechanism actually guarantees a consistent
> order of the whole configuration file. Changes to the model can also be
> verified on the persisted model (synapse.xml). This turned out to be very
> handy.
> >
> > For a couple of reasons I was now investigating whether it would make
> sense to rather just write a custom builder to create a synapse
> configuration from our specific configuration store and than use Synapse
> built-in support for serialization to XML:
> >
> > XMLConfigurationSerializer.serializeConfiguration(synapseConfiguration,
> >   new FileOutputStream(synapseConfigFileName));
> >
> > This way I should be able to get rid of a bunch of code while increasing
> flexibility. To make this work at least the issue reported yesterday as well
> as the ordering problem would need to be resolved.
> >
> > Later on if there would be a way to configure/set the configuration
> builder to use (e.g. via a factory mechanism), one could have the
> possibility to run directly based on the external (versioned) config store
> without using the intermediate step of synapse.xml.
> >
> > Any thoughts on this?
> >
> >
> > Regards,
> >  Eric
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@synapse.apache.org
> For additional commands, e-mail: dev-help@synapse.apache.org
>
>


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

Mime
View raw message