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).
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! Thanks, Otis ---- On Mon, 13 Oct 2003, Matthew Firth ([EMAIL PROTECTED]) 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! > > > >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: [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]
