synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Saminda Abeyruwan <samin...@gmail.com>
Subject Re: DeprecationMediator
Date Tue, 13 Dec 2005 05:52:22 GMT
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 <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