otisg wrote:

Just a thought for solving this problem for Matthew Firth, and a
suggestions for Chain developers (I have not looked at the
sources yet, so forgive me if this has already been
implemented).


Chain does what you describe below already (although it doesn't solve Matthew's problem).

It may be nice to allow components of a chain to process
'special messages' passed through them as messages with some
'component instructions'.
For instance, one could create a 'component instruction' to tell
the component that holds a DB connection pool, to set the pool
size to X. Or, if some component uses some code that involves
timeouts, one could pass a 'component instruction' to tell that
component to change the timeout to Y. Finally, one could
combine multiple 'component instructions' in a single object,
and pass such an object into the chain.
Maybe this is how Matthew could collect information from
different components in his chain, without iterating through
them.
Maybe this is not the right way to do it, and if so, I'm all
eyes!



The purpose of a Command is to make some change in the state of a computation, where the state is represented in the Context that is passed in to the execute() method. To implement "component instructions", then, just means you build a Command that looks for configuration parameters under some agreed-upon keys in the Context (which is a Map with some extra functionality), and then performs the task and stores its output in the Context under some other agreed upon key.


Note, however, that the chain itself has no notion of what a "component instruction" is -- all it knows is keys and values in the Context. Interpreting a "component instruction" would have to be something you built in to your Command implementations, not the commons-chains APIs themselves.

Thanks,
Otis


Craig



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to