synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sanjiva Weerawarana <sanj...@opensource.lk>
Subject Re: DeprecationMediator
Date Tue, 13 Dec 2005 19:05:23 GMT
I don't think its a good idea to have a bunch of XML or other config
files. Config files are evil things that make the user experience worse,
not easier. Furthermore think of distributing the stuff to a cluster-
now you have to distribute stuff that Synapse does not know about. 

IMO the approach should be all config is in the synapse config store
(file or otherwise) and other network accessible places (aka URLs)
pointed to by the Synapse config. Otherwise it becomes pretty impossible
to distribute and cluster stuff nicely and easily.

Sanjiva.

On Mon, 2005-12-12 at 22:35 -0800, Saminda Abeyruwan wrote:
> 
> 
> 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 
>                 
>                 
>                 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
>                 
>                 
>          
>         
>         
> 


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


Mime
View raw message