synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mukund Balasubramanian" <muk...@infravio.com>
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
simplistic.

 

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

 

1.	All configuration values must be encoded to be <name> <value>
pairs.
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 [mailto:samindaa@gmail.com] 
Sent: Tuesday, December 13, 2005 12:06 PM
To: synapse-dev@ws.apache.org
Subject: Re: DeprecationMediator

 

 

On 12/12/05, Rajesh Koilpillai <rajesh@infravio.com> 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
data.

 

Thanks,

- 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. :) 

Saminda 

	 

	
  _____  


	From: Saminda Abeyruwan [mailto:samindaa@gmail.com] 
	Sent: Tuesday, December 13, 2005 11:22 AM
	To: synapse-dev@ws.apache.org
	Subject: Re: DeprecationMediator

	 

	Hi,
	
	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 ClassLoader. 
	
	Saminda 

	On 12/12/05, Vikas <vikas@infravio.com> wrote:

	Hi,

	Comments inline. 

	 

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

		From: Paul Fremantle <mailto:pzfreo@gmail.com>  

		To: synapse-dev@ws.apache.org 

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

		Subject: DeprecationMediator

		 

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

		<Vikas> 

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

		 </Vikas> 

		
		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: 
		
		e.g. 
		<dep:deprecate> 
		  <deprecationConfig>
		      ... config goes here
		  </deprecationConfig>
		  <fault> <!-- do this if deprecated -->
		     <faultinfo...>
		  </fault>
		</dep:deprecate>

		<Vikas>

		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.

		</Vikas>

		Paul

		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. 

		~Vikas

	 

 


Mime
View raw message