"Mueller, Franz" wrote:
> Hi Craig,
>
> Our web-app looks like:
>
> ActionServletMain
>
> ActionServletModule1 ActionServletModule2 ...
>
>
> All of the controllers are living in the same web-app.
> The main controller is the only instance which knows about all the
> module-controllers.
> The communication between a module controller and the main controller is
> minimal.
> Each of the controllers has its own set of JSP/HTML-pages which are located
> in its own subfolders.
> The file structure looks like: %web-app%\
> 'main' ui
>
> module1\
> 'module1' ui
> module2\
> 'module2' ui
> ...
>
> The reasons for the modularisation are:
> 1. each module can exist in its own web-app
> 2. each module is developed by a different group
>
> Each module has ist own extension-mapping. So the requests with the
> extension *.main are served by the ActionServletMain, and *.m1 by the
> ActionServletModule1 and so on.
>
OK, just be aware that if you actually migrate them into separate webapps the
session information will be separated as well.
>
> You mentioned:
> Craig::>>servlet context attributes set up by the ActionServlet instances
> that started first to
> Craig::>>be wiped out by the attributes created
> Craig::>>in the ActionServlet instance that started last ...
>
> Since we are using Struts just as a controller framework and are NOT using
> any Struts tags,
> are we on the safe side ?
> What are the smoking guns in such a model ?
>
> The attributes, that the ActionServlet is setting in the application and in
> the session scope (like Locale ) are
> they required for the controller part of Struts or for the Struts-tags ?
>
The controller servlet initializes the following servlet context attributes,
under the keys identified in square brackets:
* The generic DataSource object if you have initialized one
under the default key. [org.apache.struts.action.DATA_SOURCE]
* The ActionFormBeans collection that is the lookup table for everything
configured in the <form-beans> section of your struts-config.xml file.
[org.apache.struts.action.FORM_BEANS]
* The ActionForwards collection that is the lookup table for everything
configured in the <global-forwards> section of your struts-config.xml file.
[org.apache.struts.action.FORWARDS]
* The ActionMappings collection that is the lookup table for everything
configured in the <action-mappings> section of your struts-config.xml file.
[org.apache.struts.action.MAPPINGS]
* The MessageResources implementation for your application
resources object. [org.apache.struts.action.MESSAGE]
If you have more than one instance of ActionServlet (even if it is subclassed)
in the same webapp, you will run into problems if you depend on any of the
above -- which is almost impossible to avoid in a Struts based application.
For example, the only mappings that will be visible are those loaded from the
last struts-config.xml file that was processed, because the ActionMappings
collection is a global variable per webapp.
>
> Best Regards, fm
Craig