Brandon Goodin:
I know there are some issues regarding reloading the struts-config.xml without a restart of the server. But, would there be any issues in regards to reloading the form-bean and form-property configuration elements? The only reason why I ask is regards to testing. Often when I am hardcoding ActionForm classes I don't have to restart the server when I make changes to the class. But, if I am using the form-property in the struts-config.xml, I have to restart the server each time. I would be more than happy to explore a patch. But, I was just wondering what the developer's experties would advise. This would really entail repopulating the FormBeanConfig and FormPropertyConfig.
David Graham:
You don't have to restart the entire server, just reload your app. Tomcat provides a manager application to do this and other containers do as well.
Craig R. McClanahan:
> I know there are some issues regarding reloading the struts-config.xml > without a restart of the server. But, would there be any issues in regards > to reloading the form-bean and form-property configuration elements?
Two major ones:
- We'd have to synchronize all accesses to the config structures,
thereby slowing down all the lookups.
- Even if we allowed you to modify struts-config.xml dynamically,
that wouldn't enable access to new or replaced classes (actions, form beans, etc.) that might have come along at the same time. Doing half a change would be *much* more confusing than not doing it at all. > But, if I am using the form-property in the struts-config.xml, I > have to restart the server each time. I would be more than happy to explore > a patch. But, I was just wondering what the developer's experties would > advise. This would really entail repopulating the FormBeanConfig and > FormPropertyConfig.
If we allow dynamic reloads of the config, people are going to expect dynamic reloads of the classes as well. That is not something Struts can provide – that's the container's issue.
Sounds like you should investigate the dynamic application reload facilities of your servlet container. I use Tomcat very heavily for development, taking advantage of the Manager webapp and its support for custom Ant tasks:
http://jakarta.apache.org/tomcat/tomcat-4.1-doc/manager-howto.html
and the only time I ever restart Tomcat is to switch versions. A typical "ant reload" command for a big Struts app takes less than 3 seconds.
Kent Sølvsten Rasmussen:
Wouldn't it be possible to solve the first issue by using the "FastMap" implementations in commons-collections?
But anyway, toying with class reloading inside Struts is not a good idea, I guess. (I suppose I am not the only one having fun with classloaders and commons-logging, and these challenges are not likely to become less, if Struts starts using its own classloader).
Craig R. McClanahan:
> Wouldn't it be possible to solve the first issue by using the "FastMap" implementations in commons-collections?
It was that way in 1.0, but it's irrelevant in 1.1.
> But anyway, toying with class reloading inside Struts is not a good > idea, I guess. (I suppose I am not the only one having fun with > classloaders and commons-logging, and these challenges are not likely to > become less, if Struts starts using its own classloader).
J2EE containers won't let apps create classloaders without lots of special handwaving (i.e. editing of security manager permissions files).
Hassan Reyes:
I tried to use a PlugIn to add some properties config beans to the form bean config every time when the instanceof my interface be true.
it was somthing like this: formBeanCfg.addFormPropertyConfig(myFormPropertyConfig); It was because i'm using DynaForms and what i want to do is like a extend my DynaFormBean but with my owns properties. Why on a PlugIn? Well because the FormBeanCfgs are not freeze jet...
Everithing looks good, but when i run my app the dispatch method has the form parameter null and i really don't know why... Does it is a good idea? or there is a best way? Thks.