synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anantharam S <ananthar...@gmail.com>
Subject Re: DeprecationMediator
Date Wed, 14 Dec 2005 12:19:13 GMT
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