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 17:34:26 GMT
On 12/13/05, Mukund Balasubramanian <mukund@infravio.com> wrote:
>
>  This does not satisfy the need to manipulate resources at runtime which
> might be an important requirement from an "enterprise management"
> standpoint. It is entirely fathomable that I do NOT want to restart my
> instance to change something like a log level.
>
>
>
> Maybe we should come up with a hot deployment model, maybe we need to come
> up with a interface to load/store but META-INF in my opinion is too
> simplistic.
>

If a a mediator  is deployed as  an .aar in  SynapseEnvironment,  then  by
default the mediator author will have hot deployment. It's just a matter of
enabling following property in Axis2.xml
<parameter name="hotupdate" locked="false">true</parameter>, so the mediator
author can do whatever she wants in an  .aar  and  deployed it. {should be
valid btw}

As i mentioned earlier in the tread, we need a generic way of handing
mediator parameters.

As Mukund intentioned, Name/Value with Value object might/not pointing to a
external resource is kinda of cool.

Paul has a criteria for M1 release, so i think most of the properties can
wait till M2 :)

Saminda


>
>
>
>
>  ------------------------------
>
> *From:* Saminda Abeyruwan [mailto:samindaa@gmail.com]
> *Sent:* Tuesday, December 13, 2005 12:06 PM
> *To:* synapse-dev@ws.apache.org
> *Subject:* Re: DeprecationMediator
>
>
>
>
>
> 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 <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