On Mon, 6 May 2002, Nicolas De Loof wrote:

> Date: Mon, 6 May 2002 14:42:31 +0200
> From: Nicolas De Loof <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: Struts Users Mailing List <[EMAIL PROTECTED]>
> Subject: org.apache.struts.action.ReloadAction and other administrative
>     actions : deprecated ?
>
> Hi
>
> I use struts-blank application as a canvas for a new struts 1.1 application,
> and so looked into included struts-config.xml.
>
> I'm surprised to see that administrative actions (like AddFormBeanAction or
> ReloadAction) are not any more in struts 1.1 b1 distribution (zip), but are
> referenced by this config file and javadoc.
>
> Are they deprecated ?
>

Yes ... I need to go make that clear in the docs.

There are a few problems with the dynamic actions:

* They require that all of the Struts collections used to store the
  set of application configuration stuff to be lockable, which is a
  performance hit for the majority use case of configurations that
  are established at startup time.

* Not every app server in the world lets you dynamically add
  new classes to a running application, so they are not
  universally usable.  At the same time, the ability to redeploy
  apps quickly in development (such as in Tomcat) has been
  radically improved in many servers and development tools
  over the last couple of years.

* The fact that the trees of configuration objects could change
  over time in 1.0 can lead to accidental bugs (due to unintended
  calls to the methods that add and remove things) as well as
  making the behavior of a Struts app much less deterministic
  (and therefore harder to understand).

* They represent a security risk to apps that simply copy the
  struts-config.xml file from the example app and don't remember
  to remove (or protect) these action mappings.

It's feasible that I could be persuaded to change my mind on this, but it
is an area that has caused some people problems.

Craig


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to