synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rajesh Koilpillai" <>
Subject RE: DeprecationMediator
Date Tue, 13 Dec 2005 06:09:48 GMT
Hi Saminda,


Yes, synapse.xml should not be made more complex & mediator specific
configuration should be separately stored / retrieved.

But storing some of this information inside the META-INF folder of the .aar
file might not be a good thing to do, you would rather want to store them
externally as you might want to manipulate some of this configuration during
runtime. Also apart from configuration it might have to deal with other
mediator specific resources like xsl files or other mediator specific
content. It's better to externalize this storage & so that there is a clean
interface to load / modify configuration data.



- Rajesh Koilpillai



From: Saminda Abeyruwan [] 
Sent: Tuesday, December 13, 2005 11:22 AM
Subject: Re: DeprecationMediator



DeprecationMediator is a very good example. It gives us focus on where
mediators are looking for some resource, it may be a xml file, properties
file, etc. When mediators called via <servicemediator/>and  if a mediator
needs a resource, implementing EnvironmentAware interface and giving the
correct ClassLoader object to the Mediator is kinda cool idea. 

We shouldn't make synapse.xml more complex with every add on, but if we can
give a generic syntax to read xml data to a mediator that is really cool. On
the other hand, in <servicemediator/> we already have a solution. Put
whatever resources in META-INF folder of the .aar file and get the correct


On 12/12/05, Vikas <> wrote:


Comments inline.


----- Original Message ----- 

From: Paul <>  Fremantle 


Sent: Tuesday, December 13, 2005 3:20 AM

Subject: DeprecationMediator



I'm looking at the deprecation mediator. Great idea!

At the moment it drops any deprecated messages. I think there are two more
useful approaches...

1. It sets a property, but lets the message flow on. Then a rule checks for
the property and can, for example use <fault> to fault. 


This can be done even with the current code, its about leveraging the power
of Synapse's rule processing. 

The property "synapse.deprecation.result" addressed through
"DeprecationConstants.CFG_DEPRECATION_RESULT" is set anyways :-)

No changes needed to DeprecationMediator (except maybe, when we all settle
for what a return false/true and a set/null WSATo does. You had sent a mail,
but then we never discussed it, personally i'd give a +1). 


2. We could rewrite it as a plugin processor. In this model, it could have
the "deprecation config" as a child element or attribute, and then there
could be nested children are executed if the service is deprecated: 

      ... config goes here
  <fault> <!-- do this if deprecated -->


The idea was to not crowd/clutter the Synapse.xml, thought it would be
better to have a separate file to hold all deprecationConfig. That would
leave the   

DeprecationConfigurator as an internal thing and allow a 'dev' to get/store
config info from any source he/she wants, leaving the stuff transparent to
the 'rule-writer' or the person who configures the deprecation details.



Had thought of these but settled for the current code. But then, its there
to evolve.

Thanks for the comments Paul. Saminda - Thanks to you too. 



View raw message