commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: [chain] no chain iterator?
Date Mon, 13 Oct 2003 21:59:45 GMT
Matthew Firth wrote:

>>>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!
>  
>

Sounds like a reason to subclass ChainBase for your own chain 
implementations.

Or, if you're using the org.apache.commons.chain.config package to 
configure the chains, you could go re-parse the configuration document 
yourself, and find out not only how the chains were configured, but what 
property settings were done on all the Chain and Command instances.

>
>  
>
>>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.
>
>  
>

It's definitely internal.  From the outside, you should think of a Chain 
as a *Command*, not a chain.  In fact, that's why Catalog has a 
getCommand() method, not a getChain() method.  Whether the code is 
internally implemented as a chain or not is irrelevant to users -- 
that's an implementation detail.

>  
>
>>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 :)
>  
>

So you propose to make it *public* instead *package protected*?  That 
doesn't seem like an improvement.

The logical extension of *that* argument says we shouldn't ever use 
private variables for anything :-).

>
>  
>
>>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.... :)
>  
>

-1 on this proposed change, for the reasons discussed on this thread.

>
>matthew
>  
>

Craig



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


Mime
View raw message