Re: [chain] no chain iterator?

[Craig R. McClanahan]

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]