Ok, thanks, that is exactly what I have been doing, and I'm glad to hear that others recommend the same approach.
Otis ---- On Mon, 13 Oct 2003, Craig R. McClanahan ([EMAIL PROTECTED]) wrote: > 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] > > > ________________________________________________ Get your own "800" number Voicemail, fax, email, and a lot more http://www.ureach.com/reg/tag --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]