On Mon, 3 Feb 2003, Susan Bradeen wrote:

> Date: Mon, 3 Feb 2003 13:24:10 -0500
> From: Susan Bradeen <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Multiple struts-config files without Modules
>
> Without using Modules, and given the following configuration:
>
> <!-- Standard Action Servlet Configuration (with debugging) -->
>   <servlet>
>     <servlet-name>action</servlet-name>
>     <servlet-class>org.apache.struts.action.ActionServlet</servlet-class>
>     <init-param>
>       <param-name>config</param-name>
>       <param-value>
>                 /WEB-INF/struts-config.xml,
>                 /WEB-INF/struts-config-SectionOne.xml,
>                 /WEB-INF/struts-config-SectionTwo.xml
>         </param-value>
>     </init-param>
>     ...
>     <load-on-startup>1</load-on-startup>
>   </servlet>
>
> Is there a proper order for the list of config files? Is there any
> advantage to having the struts-config.xml listed first or last?
> Preliminary tests show that I can put global <forwards>, <exceptions>, and
> <actions> in any of the config files, and Struts seems to find it. Even
> having a DynaActionForm in one config file, and action mappings that
> reference it in another config file, seems to work fine. Does Struts
> somehow actually consider the three files to be one? I started using this
> for "organizational" purposes mainly, but I am curious if there are any
> pitfalls that I should be aware of.
>
> Any comments are appreciated.
>

If the contentes of your three files are constructed correctly (i.e. you
don't try to declare the same <action> path more than once, for example),
then order does not matter at all -- Struts simply processes all of the
files at initialization time.  The ability to split is simply for the
convenience of the application developer (particularly when you might have
different subteams responsible for different parts of a single large
single-module app).

> Susan Bradeen
> SoftLanding Systems, Inc
> [EMAIL PROTECTED]
>

Craig

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

Reply via email to