You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@synapse.apache.org by Paul Fremantle <pz...@gmail.com> on 2006/11/28 18:26:08 UTC

Re:

Andrej

We actually do both of the above too :-) I'm afraid our documentation
isn't that clear.

Basically we have this concept of a "registry". You can load XML
fragments from the registry (maybe just a URL) and then the overall
synapse.xml will be glued together from those fragments. These are
known as dynamic properties.

As part of this, these dynamic properties are reloaded based on a
cache setting for the registry provider. So new messages coming in
will pick up these updated xml configs.

You can find more information here:
http://svn.apache.org/viewvc/incubator/synapse/trunk/java/src/site/resources/Synapse_Configuration_Language.html?content-type=text%2Fhtml&view=co

At the moment the only "registry" we support is just a URL source
(e.g. filesystem or HTTP server), but the interface is pluggable.
Would you be interested in writing a plugin to support grabbing those
XML fragments from freebXML?

Paul



On 11/28/06, Andrzej Jan Taramina <an...@chaeron.com> wrote:
> Hi:
>
> New to the list.  Been working on some XML pipeline and intermediary stuff of
> late and thought there might be some overlap with what Synapse is trying to do.
>
> I was wondering if any thought has been given to allowing the use of multiple
> synapse.xml config files?
>
> More specifically, if you want to mediate a lot of different transmission types,
> then the synapse.xml file can get rather large and unweildy to maintain. Being
> able to use multiple config files, with some sort of selector mechanism (eg.
> regex, xpath, etc.) which would figure out which config file applies to a
> particular incoming transmission would be very useful.
>
> On a related note, is there any way to dynamically reload the config file(s) at
> runtime?  If the config file is located on a remote server and accessed with a
> URL, it would be nice if there was some sort of callback that could be invoked
> into the Synapse server to have it reload a particular config file.  This stems
> from some of the work I've been doing using SOA Registry/Repositories, which
> would be ideal for the governance and storage of the mediation configuration
> documents (eg. synapse.xml).
>
> My current SOAP Intermediary implementation (part of freebxml ebXML Reg/Rep OSS
> project) does both of the above.
>
>
>
> ...Andrzej
>
> Chaeron Corporation: Enterprise System Solutions
> http://www.chaeron.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: synapse-user-unsubscribe@ws.apache.org
> For additional commands, e-mail: synapse-user-help@ws.apache.org
>
>


-- 
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair

http://bloglines.com/blog/paulfremantle
paul@wso2.com

"Oxygenating the Web Service Platform", www.wso2.com

---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-user-help@ws.apache.org


Re:

Posted by "Asankha C. Perera" <as...@wso2.com>.
Andrej

Also check Sample # 9 onwards at 
http://svn.apache.org/viewvc/incubator/synapse/trunk/java/src/site/resources/Synapse_Samples.html?content-type=text%2Fhtml&view=co#Sample9

The Synapse site would be updated soon with this documentation - as 
quite a few outdated docs are available elsewhere unfortunately..

asankha

Paul Fremantle wrote:
> Andrej
>
> We actually do both of the above too :-) I'm afraid our documentation
> isn't that clear.
>
> Basically we have this concept of a "registry". You can load XML
> fragments from the registry (maybe just a URL) and then the overall
> synapse.xml will be glued together from those fragments. These are
> known as dynamic properties.
>
> As part of this, these dynamic properties are reloaded based on a
> cache setting for the registry provider. So new messages coming in
> will pick up these updated xml configs.
>
> You can find more information here:
> http://svn.apache.org/viewvc/incubator/synapse/trunk/java/src/site/resources/Synapse_Configuration_Language.html?content-type=text%2Fhtml&view=co 
>
>
> At the moment the only "registry" we support is just a URL source
> (e.g. filesystem or HTTP server), but the interface is pluggable.
> Would you be interested in writing a plugin to support grabbing those
> XML fragments from freebXML?
>
> Paul
>
>
>
> On 11/28/06, Andrzej Jan Taramina <an...@chaeron.com> wrote:
>> Hi:
>>
>> New to the list.  Been working on some XML pipeline and intermediary 
>> stuff of
>> late and thought there might be some overlap with what Synapse is 
>> trying to do.
>>
>> I was wondering if any thought has been given to allowing the use of 
>> multiple
>> synapse.xml config files?
>>
>> More specifically, if you want to mediate a lot of different 
>> transmission types,
>> then the synapse.xml file can get rather large and unweildy to 
>> maintain. Being
>> able to use multiple config files, with some sort of selector 
>> mechanism (eg.
>> regex, xpath, etc.) which would figure out which config file applies 
>> to a
>> particular incoming transmission would be very useful.
>>
>> On a related note, is there any way to dynamically reload the config 
>> file(s) at
>> runtime?  If the config file is located on a remote server and 
>> accessed with a
>> URL, it would be nice if there was some sort of callback that could 
>> be invoked
>> into the Synapse server to have it reload a particular config file.  
>> This stems
>> from some of the work I've been doing using SOA 
>> Registry/Repositories, which
>> would be ideal for the governance and storage of the mediation 
>> configuration
>> documents (eg. synapse.xml).
>>
>> My current SOAP Intermediary implementation (part of freebxml ebXML 
>> Reg/Rep OSS
>> project) does both of the above.
>>
>>
>>
>> ...Andrzej
>>
>> Chaeron Corporation: Enterprise System Solutions
>> http://www.chaeron.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: synapse-user-unsubscribe@ws.apache.org
>> For additional commands, e-mail: synapse-user-help@ws.apache.org
>>
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: synapse-user-unsubscribe@ws.apache.org
For additional commands, e-mail: synapse-user-help@ws.apache.org