[snip]
While we're on the thread, I remembered one other thing: right now, the configuration freezes each module config. I've never been 100% clear on why Struts uses 'freeze' to lock things down. Is there any legitimate reason for more than one configurator to be involved in setting up a ModuleConfig? If so, we need to either take out the freezing or push it up into ActionServlet to do after it has given each StrutsConfigurator a chance to do its thing. In my "draft", I just left the moduleConfig.freeze() inside the "ClassicConfigurator", but I wanted to check on this question.
The original motivation for freezing the configuration was to allow HashMap lookups during execution to run without time-wasting (for the 99.9% use case) synchronization. When 1.1 introduced PlugIn, we also moved the freeze() call to after PlugIns have executed their initialization, so that PlugIns can dynamically modify the configuration information as well. We'd certainly want to do the same thing with configurators ... not freeze until they've all had their shot at updating the configuration.
I personally believe that, even if we implemented dynamic reconfiguration support for the config files themselves, developers will be disappointed in how little this helps in a development cycle -- you're not going to pick up added or changed Java classes without a container-managed restart of the webapp (except on *some* containers where you haven't yet loaded the class in question), so typical development use cases like "add the next Action" are going to require restarts anyway.
Just thought of one more thing: technically, since the Configurator has access to the entire ServletContext, should we have a destroy() method also? I would kind of prefer to leave that out and keep it simple, since otherwise it might get confusing about where cleanup responsibilities lie... but we may not be able to avoid it. (Then again, we may be able to wait until someone asks for it/has a use case.)
Yes, I can see use cases for this (such as saving current state information that will be used the next time the configuration is loaded). But if you add a destroy method, haven't you just recreated the PlugIn API? Indeed, isn't configuring Struts just a special case of what PlugIn is for (albeit its one that we'd probably want to ensure ran before user-defined PlugIns)?
Joe
Craig
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
