The problem with ReloadAction was that Struts was trying to act like a container, but it couldn't do a proper job of it. For EXAMPLE, you can't reload classes that have been modified, or (portably) add new classes to a running web application (even if the container supported it). 

Meanwhile, as Struts 1.1 was being developed, work PROGRESSED on THINGS like Tomcat's reload command via the Manager webapp. This feature allows you to quickly reload-on-demand, complete with saving and restoring your SESSION). It started to make even less sense for Struts to half-implement a feature that containers are implementing fully.

A more minor point is that freezing the configuration information at application startup time allows Struts to safely access the mapping information without bothering with synchronization. The "startup-only" strategy creates a modest but real improvement in performance for all users. 

So, ReloadAction is not supported since Struts 1.1 for two reasons:

* It never did let you reload everything that you would really WANT to -- particularly changed classes -- so many people ended up having to reload the webapp anyway.
* Containers are starting to offer reload-on-demand features which does the same thing as the Struts ReloadAction, only better.
* Not supporting ReloadAction lets Struts avoid doing synchronization locks around all the lookups (like figuring out which action to use, or the destination of an ActionForward) so applications can run a little faster.

Of course, if someone came up with an implementation that solved these problems without creating any others, we would not be opposed to including a new ReloadAction.

The problem with ReloadAction was that Struts was trying to act like a container, but it couldn't do a proper job of it. For example, you can't reload classes that have been modified, or (portably) add new classes to a running web application (even if the container supported it). 

Meanwhile, as Struts 1.1 was being developed, work progressed on things like Tomcat's reload command via the Manager webapp. This feature allows you to quickly reload-on-demand, complete with saving and restoring your session). It started to make even less sense for Struts to half-implement a feature that containers are implementing fully.

A more minor point is that freezing the configuration information at application startup time allows Struts to safely access the mapping information without bothering with synchronization. The "startup-only" strategy creates a modest but real improvement in performance for all users. 

So, ReloadAction is not supported since Struts 1.1 for two reasons:

* It never did let you reload everything that you would really want to -- particularly changed classes -- so many people ended up having to reload the webapp anyway.
* Containers are starting to offer reload-on-demand features which does the same thing as the Struts ReloadAction, only better.
* Not supporting ReloadAction lets Struts avoid doing synchronization locks around all the lookups (like figuring out which action to use, or the destination of an ActionForward) so applications can run a little faster.

Of course, if someone came up with an implementation that solved these problems without creating any others, we would not be opposed to including a new ReloadAction.