> 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.
Now that would be cool. I think we would have to load all clay config files to resolve the inheritance dependencies but that would be way slick. Gary > > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
