synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sathish Kumar TK" <Sath...@infravio.com>
Subject RE: DeprecationMediator
Date Wed, 14 Dec 2005 12:49:55 GMT
Just copied it into the message. Find the attachment now.
  -----Original Message-----
  From: Anantharam S [mailto:anantharams@gmail.com]
  Sent: Wednesday, December 14, 2005 5:49 PM
  To: synapse-dev@ws.apache.org; Sathish@infravio.com
  Subject: Re: DeprecationMediator


  the attachment comes as unnamed.. no extension !!


  On 12/14/05, Sathish Kumar TK <Sathish@infravio.com> wrote:
    Giving an example to what Mukund said:
    1) Loads CRL details from a property file.
    2) If needed, modify it.
    3) Once updated, the changes gets saved in to the property file and also
    gets pushed into an MBean so that CRL verification module can have the
    latest.

    Thanks
    Sathish







    -----Original Message-----
    From: Mukund Balasubramanian [ mailto:mukund@infravio.com
    <mailto:mukund@infravio.com> ]
    Sent: Wednesday, December 14, 2005 10:32 AM
    To: synapse-dev@ws.apache.org
    Subject: RE: DeprecationMediator


    Sanjiva:

    While hot deployment might work, it is important to realize that the
    modification at runtime might not require a full reload of the
    configuration.

    I believe I had given the example of modifying log levels, there might
    be other examples like CRL pointers for security, additional hosts for
    load balancing all of which could happen any time and should not require
    a restart.

    I continue to opt for a simple configuration model (NV, V could be
    simple - including url or file) which can be defaulted using synapse
    config but also allows runtime modification.

    I would be happy to prototype this if it continues to be unclear.

    Mukund Balasubramanian

    -----Original Message-----
    From: Sanjiva Weerawarana [ mailto:sanjiva@opensource.lk
    <mailto: sanjiva@opensource.lk> ]
    Sent: Wednesday, December 14, 2005 12:35 AM
    To: synapse-dev@ws.apache.org
    Subject: Re: DeprecationMediator

    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 < 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
    <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
    >
    >
    >                 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



    ---------------------------------------------------------------------
    To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
    For additional commands, e-mail: synapse-dev-help@ws.apache.org




    ---------------------------------------------------------------------
    To unsubscribe, e-mail: synapse-dev-unsubscribe@ws.apache.org
    For additional commands, e-mail: synapse-dev-help@ws.apache.org




Mime
View raw message