You could use / write a common configuration framework, which would be instantiated by the action servlet, and where all configuration objects are stored / managed. An action would then obtain it's specific configuration object in constructor, or even better in execute(). Last one would allow to change the configuration on the fly, without restart or anything.
Actually we are using something like this but for services. It's based on propertyfiles and a simple watcher thread, which checks all registered files, and if they changes calls: notifyConfigurationStarted(); setProperty(name, value) for each property in file notifyConfigurationFinished(); it's absolutely simple, but works superb, we are using it to reconfigure caches, switch databases switch legacy systems on and off. Is it IoC enough for you?:-) Regards Leon > -----Ursprüngliche Nachricht----- > Von: Frank W. Zammetti [mailto:[EMAIL PROTECTED] > Gesendet: Sonntag, 6. März 2005 00:14 > An: Struts Users Mailing List > Betreff: Re: Eliminate Setup Actions > > Sure, that would work. But, then you are limiting the > developer to basically one setup per class, or forcing them > to do some work that Struts really should be doing... > > If I were to add something like this to Struts (and I have > enough interest in this idea that I'd love to persue it, > assuming there is some general interest), one of the > requirements in my mind would be the ability to call any > number of setup methods per mapping. > > For instance, maybe I have a page with 10 different > dropdowns. Maybe I determine that the way I want to > implement that setup is to have ten different methods in my > setup class and specify them all to execute in the mapping. > Sure, I could call all ten of them from the constructor, but > that just *feels* like a bit of a hack to me. I'd prefer a > more IoC-esque approach, and this feels like the exact > opposite. I'd want to be able to explitidly declare the ten > methods I want executed (and in the stated order of course) > rather than having to code that functionality into the setup > class itself, which is what I'd be forced to do in the > constructor (ditto for a static block). > > There is a debate in my mind whether the setup class should > have to implement some given interface... It makes sense to > do so because then Struts can be sure the class is of an > appropriate type for the task. > But, to allow for multiple setup methods the interface would > have to be defined to include setupMethod1(), setupMethod2(), > setupMethod3() and so on. That's pretty obviously a bad > design. So, I imagine the interface would pretty much just > be a tag interface, and we would have to assume that if the > developer implements the interface, then whatever methods are > present in the class are meant for setup. Like I said > though, there's a bit of debate in my own head on this point > right now. > > -- > Frank W. Zammetti > Founder and Chief Software Architect > Omnytex Technologies > http://www.omnytex.com > > Leon Rosenberg wrote: > >>... I figured you'd specify > >>the class and method to call, although even easier would be > to write > >>an actual SetupAction class, or something along those lines, with a > >>known interface that all these classes would have to > implement, then > >>you would just specify the class and Struts would know what > method to > >>call. > > > > > > Erm, what about the constructor? Or the static{} part? > > > > Regards > > Leon > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > . > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
