You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@synapse.apache.org by Paul Fremantle <pz...@gmail.com> on 2005/12/12 22:50:14 UTC
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.
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>
Paul
Re: DeprecationMediator
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
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 <ra...@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 <vi...@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
Re: DeprecationMediator
Posted by Saminda Abeyruwan <sa...@gmail.com>.
On 12/12/05, Rajesh Koilpillai <ra...@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* <vi...@infravio.com> wrote:
>
> Hi,
>
> Comments inline.
>
>
>
> ----- Original Message -----
>
> *From:* Paul Fremantle <pz...@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*
>
>
>
RE: DeprecationMediator
Posted by Rajesh Koilpillai <ra...@infravio.com>.
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
_____
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 <vi...@infravio.com> wrote:
Hi,
Comments inline.
----- Original Message -----
From: Paul <ma...@gmail.com> 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
Re: DeprecationMediator
Posted by Saminda Abeyruwan <sa...@gmail.com>.
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 <vi...@infravio.com> wrote:
>
> Hi,
>
> Comments inline.
>
>
> ----- Original Message -----
>
> *From:* Paul Fremantle <pz...@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*
>
>
Re: DeprecationMediator
Posted by Vikas <vi...@infravio.com>.
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