----- Original Message -----
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.
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>
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.
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.
|
- Re: DeprecationMediator Vikas
-
