On 7/27/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Sergey, > > > Now, I have to restart my servlet container each time I have even small > > changes in the clay configuration file. I have not to do it for java > > classes, bundles, jsps. Development the UI with Clay might be much more > > faster if clay config file will be updated on the fly. > > Does any plan to avoid restarting exist? > > > > Currently the clay configuration files are loaded by a context listener on > application startup. The meta-data is cached in application scope. > > I don't see a reason why we couldn't reload it on the fly. It seems like > struts had the same feature in the early releases allowing an action to > reload the struts-confg files. I'm positive that someone listening here could > tell us the history and why the decision was made to remove it.
Boy, you guys *really* want to go back to history, don't you? :-) It is indeed true that Struts 1.0 supported (by default) a "reload" action that would load the Struts configuration files over again. This was removed for several reasons that were valid at the time (and some of them are no longer relevant): * The possibility of changing the configuration information on the fly meant you really needed to synchronize on every *read* of the configuration maps, even though (for most users) this would never happen. In the days of early JDK 1.2, this was a *serious* performance issue (and led to the decision (in Struts 1.1) to make the configuration data immutable so that no locks were necessary for the normal case. Modern JDKs make this so much a non-issue that it is not worth worrying about any more. * The particular mechansim by which Struts 1.0 implemented this feature led to a potential denial-of-service attack (because of the performance overhead of doing all the parsing), primarily because it was enabled by default with no security constraints. This by itself could have been dealt with in other ways, but the previous point dominated the thinking when Struts 1.1 was being designed. * In a Struts 1.x world, the value of just reloading the config information is not (IMHO) all that valuable unless it could be coupled with the ability to load revised Java classes (Action and ActionForm implementations are the most releveant ones). Even today, that is not a practical reality ... but it doesn't matter when you are talking about reloading the configuration of a component tree. > > We might be able to do this with a Shale remote command. It would be kind of > fun to return an XML representation of the component meta-data after all > inheritances have been realized. The ideal architectural approach would be to (somehow periodically) examine the last modified date of the configuration resources (but do it via the URL APIs, so it works even if the app is loaded directly from a WAR file). It should not be something that has to be initiated manually ... it should be something that the framework is watching for in the background. It may still be necessary to offer a mechanism to request such a reload manually -- but the best world is where you do not have to do that. > Gary Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
