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.

  • No labels