Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Date: Tue, 14 Oct 2003 06:00:10 -0400
Message-Id: <200310141000.GAA21388@www21.ureach.com>
To: "Craig R. McClanahan" <commons-dev@jakarta.apache.org>
From: otisg  <otisg@ureach.com>
Reply-to: <otisg@ureach.com>
Subject: Re: Re: [chain] no chain iterator?
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit

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
(craigmcc@apache.org) 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:
commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
commons-dev-help@jakarta.apache.org
> 
> 
> 


________________________________________________
Get your own "800" number
Voicemail, fax, email, and a lot more
http://www.ureach.com/reg/tag

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