synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hubert, Eric" <>
Subject RE: svn commit: r753144 - in /synapse/trunk/java/modules: core/src/main/java/org/apache/synapse/mediators/builtin/ core/src/main/java/org/apache/synapse/mediators/db/ core/src/main/java/org/apache/synapse/mediators/eip/aggregator/ core/src/main/java/
Date Sat, 14 Mar 2009 10:41:24 GMT

> I may wrong but state full means outcome of the current request may be
> depend on what previous requests did. If it is session ware, then it
> depends on previous requests on the current session. Keeping life
> cycle state (initialized, destroyed), not relate with above thing. 

I agree the term state might not be properly chosen by Ruwan, but his explanation of his concerns
was understandable at least understandable to me and somehow I seem to have the same concerns.

> me, if it is good, if we can enforce that, all the mediators need to
> be properly initialized and destroyed. 

With this change you do not enforce anything. You could only enforce this by making the methods
abstract. Any empty implementation enforces nothing, or?

> Minimally, any mediator that is
> an abstract mediator (it is a mediator with some common behaviors),
> need to properly initialized and destroyed (currently it is not
> there).

Why? What about the POJOCommandMediator? If this would be the case the class name of AbstractMediator
should reflect this and the lifecycle methods should be abstract.

> It is possible to fill the blank with some useful things. For example,
> cache SynapseEnvironment or Axis2 Configuration Context... There are
> many mediators that try to access these with in mediate method by
> casting to axi2 message context, then get axi2 configuration context,
> then get synapse environment,etc …. Can completely eliminate those
> codes. Keeping SynapseEnvironment is never bad thing…..

If there is really a some common code in conjunction with managed lifecycle it might be a
better idea to create a new abstract class extending from AbstractMediator implementing those
methods and letting all mediators needing a lifecycle extending from those. Having had only
a short look at some Synapse mediators I actually doubt the benefit.

Hmmm, I did not get the full meaning of your last two sentences. I'm quite new to the Synapse
code, which maybe the reason. But if many mediators are doing the same thing (and this does
not sound to be lifecyle-dependend) then you may implement some common functionality in AbstractMediator
and use this, or?

View raw message