Multiple sub-application support?

[Amit Vaidya <am...@infosys.com>]

As per the struts documentation, ActionServlet and RequestProcessor (struts release 1.1 b1) 
supports multiple sub-applications. 

As per my understanding, "prefix" attribute in the ApplicationConfig class is being used for the 
same.

Can anyone please explain
- what exactly is meant by multiple sub-applications are supported by the same actionServlet?
- How the 'Prefix' attribute in ApplicationConfig class is used to achieve the intended result?
- Does this mean that multiple requests coming from URIs such as /test1/serv   /test2/serv2   /test3/serv3 
  are received by the single actionServlet? 

TIA,
Amit

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Multiple sub-application support?

["Craig R. McClanahan" <cr...@apache.org>]

On Mon, 15 Jul 2002, Amit Vaidya wrote:

> Date: Mon, 15 Jul 2002 14:18:39 +0530
> From: Amit Vaidya <am...@infosys.com>
> Reply-To: Struts Users Mailing List <st...@jakarta.apache.org>
> To: Struts Users Mailing List <st...@jakarta.apache.org>
> Subject: Multiple sub-application support?
>
>
> As per the struts documentation, ActionServlet and RequestProcessor
> (struts release 1.1 b1)  supports multiple sub-applications.
>
> As per my understanding, "prefix" attribute in the ApplicationConfig
> class is being used for the same.
>
> Can anyone please explain

> - what exactly is meant by multiple sub-applications are supported by
>   the same actionServlet?

> - How the 'Prefix' attribute in ApplicationConfig class is used to
>   achieve the intended result?

> - Does this mean that multiple requests coming from URIs such as
>   /test1/serv /test2/serv2 /test3/serv3
>   are received by the single actionServlet?
>
> TIA,
> Amit
>

The basic idea of sub-applications (the formal name will be "application
modules" when we release 1.1) is that you can use multiple independent
struts-config.xml files in the same web application.  This is especially
helpful in large scale applications that are maintained by multiple groups
of developers, where fighting over a single copy of struts-config.xml is
pretty painful.

You configure the multiple struts-config files with servlet init
parameters on the controller servlet -- for example:

<servlet>
    <servlet-name>Controller</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</param-value>
        <description>
            The configuration file for the "default" application module.
        </description>
    </init-param>
    <init-param>
        <param-name>config/foo</param-name>
        <param-value>/WEB-INF/foo-struts-config.xml</param-value>
        <description>
            The configuration file for the /foo application module.
        </description>
    </init-param>
    <init-param>
        <param-name>config/bar</param-name>
        <param-value>/WEB-INF/bar-struts-config.xml</param-value>
        <description>
            The configuration file for the /bar application module.
        </description>
    </init-param>
</servlet>

Now, assuming your application's context path is "/myapp", Struts looks at
the incoming request URL and determines which application module should
handle the request:

http://localhost:8080/myapp/foo/saveCustomer.do --> "/foo" module
http://localhost:8080/myapp/bar/saveCustomer.do --> "/bar" module

Any request not starting with the prefix for one of your configured
modules is handled by the "default" module.  This is the same kind of
thing your servlet container does to figure out which web application to
give a request to, based on matching the context path.

A primary goal is that any existing struts-config.xml file can be used
either as the default module (i.e. exactly how it works in 1.0, which
*only* supports a single module) or as a sub-app module, with zero
changes.  Basically, that means anything in struts-cconfig.xml that 1.0
treats as "context relative" is now "module relative" in 1.1 -- in other
words, Struts will automatically add the module prefix in where needed.
Because the prefix for the default module is "" (zero length string), the
same algorithm works, so it's not a special case.

Restrictions for using app modules include:

* Must use extension mapping (like "*.do") rather than
  path mapping ("/do/*") for the controller servlet.
  (This restriction might get relaxed after 1.1 final
  is released).

* In order to select the correct module, *all* requests
  must go through the controller servlet.  If you link
  directly to a JSP page, without going through the
  controller, that page will always think it is in the
  default module.  (This restriction cannot be lifted
  until we make Struts require Servlet 2.3, so we can
  do the necessary work with a Filter).

All requests continue to flow through a single instance of the controller
servlet, which continues to be a requirement.  But, from the application
developer's point of view, that makes no difference at all -- you feel
like you are developing just your own module (except for the ability to
share session information across modules, which is really the only reason
to combine modules into a single webapp instead of separating them).

Craig


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>