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: Mon, 13 Oct 2003 18:09:54 +1000 (EST)
From: Matthew Firth <commons-dev@matthew.matera.net.au>
To: commons-dev@jakarta.apache.org
Subject: Re: [chain] no chain iterator?
In-Reply-To: <sf8a611b.067@boney.crimecommission.gov.au>
Message-ID: <Pine.LNX.4.44.0310131801490.2470-100000@border.matera.net.au>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


>>Has anybody considered a chain iterator?
>Why do you need to do this yourself?  

The particular case I have is a "status" page that dumps the 
state of the web application - what configuration options 
have been loaded and enabled, the state of certain components
(like the size of the connection pool).  

What I was hoping to do was that for some set of Chains that 
are configured during initialisation, show the Commands that 
have been configured in each and then also interrogate each
command (reflection/bean introspection) for some of its 
properties/configurations.

Hence, my desire to be able to iterate the currently 
configured commands in a chain!


>The point of the Chain is to 
>execute the relevant Commands for you.
True, but does that mean that the chain should/must(?) become
inpenetrable after it has been created?


>Nothing like this should be added to the Chain interface itself --
>that would be exposing internal details that should be of
Given that the 'contract' of Chain is to execute some sequence
of commands in order, I'm not sure that telling an external party
what that *sequence* will be is an "internal" of the Chain.


>In addition, it would be redundant to add this to ChainBase because it
>is trivially simple to add in your own subclass of ChainBase
True enough.  I have no huge objection to doing that, but now I'm more 
interested in your reasoning than your original answer :)


>or the unit tests for the  Chain implementation (which is why the
>package private getCommands()
Using package private access to allow your unit tests better access
to the code always feels "wrong" to me.. That is probably why the 
Iterator concept makes sense in my mind... but maybe not to other 
people :)


>I would consider any other code that wants to mess 
>around with the internals of the chain as a potential danger signal 
I agree that anything that was to *change* the state of a Chain
instance is most certainly a danger signal, but I'm still not sold
on the idea that a chain can be told what to do, but nobody else
thereafter is allowed to find out about it.... :)


matthew


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