synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vikas" <>
Subject Re: DeprecationMediator
Date Tue, 13 Dec 2005 05:25:38 GMT

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