4) As I've mentioned before (in this same thread, I think), I believe we need to factor out the configuration code and make it pluggable.
Although this is Martin's fourth point, I think it should be the starting point. If we move to a way where configuration is pluggable, then someone could experiment with the classpath-scanning autoconfig until they are sure that it is workable before introducing it, and/or introduce it in a way which is clearly experimental.
I'm just making this up as I go, but what if there were an optional servlet init param which could consist of one or more class names, where each class implemented a "StrutsConfigurator" interface. Then in servlet.init(), the servlet could instantiate each and pass itself to the configure method (or maybe just pass the ServletContext, if that's safer or better).
If this parameter were undefined, the default configurator would be called (which would just be the factored out current behavior.) If the parameter were defined, then one would need to explicitly list the default configurator.
Like I said, this is kind of off the cuff, but I do think this is the first step.
While we're talking about it, we should have in mind the frequently requested feature of dynamic reloading, although I don't think we should let it stop anything.
Joe
--
Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining."
-- Jef Raskin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
