synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mukund Balasubramanian" <>
Subject RE: DeprecationMediator
Date Tue, 13 Dec 2005 11:53:29 GMT
This does not satisfy the need to manipulate resources at runtime which
might be an important requirement from an "enterprise management"
standpoint. It is entirely fathomable that I do NOT want to restart my
instance to change something like a log level. 


Maybe we should come up with a hot deployment model, maybe we need to
come up with a interface to load/store but META-INF in my opinion is too


We can simplify the mediator configuration issue by making some
fundamental assumptions:


1.	All configuration values must be encoded to be <name> <value>
2.	Value objects can be simple or external resources (bin, xml) but
not structured values.


Once we agree on these basic assumptions, the interface is pretty darn
simple, can I can fathom a direct correlation to MBeans as well.


Mukund Balasubramanian



From: Saminda Abeyruwan [] 
Sent: Tuesday, December 13, 2005 12:06 PM
Subject: Re: DeprecationMediator



On 12/12/05, Rajesh Koilpillai <> wrote:

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



- Rajesh Koilpillai

Loading resources from a external repository is acceptable. Axis2 has a
cool fetcher called "service-groups" we can share some stuff in these
"service-groups". So sometimes when using <servicemediator/> with
"service-groups" you mightn't want to use external repositories. :) .
For the time being lets use the extremal resources in META-INF and let's
have a generic way of getting resource externally later. :) 




	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
	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 ClassLoader. 

	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


		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




View raw message