action-servlet.xml (Integrating Spring With Struts)
The purpose of this configuration file is to integrate Spring with Struts 1.2 by defining your Struts Actions in your Spring configuration.
It should contain a bean entry for every action in your app and these beans should be defined as singletons (not true for Struts 2 projects). Since the beans are defined as singletons it is important to make sure the action is thread-safe (i.e., multiple users won't corrupt each other's data) which means the action class should not have any non-static instance variables. Instance variables are non-local (i.e., defined within class but outside of a method, conditional statement, loop etc) variables . Note that some of our actions have a static variable defined as a Logger. This is fine since static means everyone shares the same variable & value (think global variable across multiple users) and we want everyone to share a single log file. Check out this page for a discussion of instance versus static variables.
The bean names in action-servlet.xml must match a corresponding action path in the action-mappings section of your struts-config.xml. So for instance, in the oas-skeleton, the bean name="/EnterSearchCriteria" in the action-servlet exactly matches the action path="/EnterSearchCriteria" in the struts-config and they both refer to one of the three actions you will find in the oas-skeleton (edu.mit.oasskeleton.controller.action.EnterSearchCriteriaAction).
You won't make any changes to the bean name "/EntryAction" and most apps will have only one entry point, in which case, you won't create any additional entry actions. But your app can have any number of entry points. Each of the entry points would have an action that is configured in struts-config to be chained to an action-servlet bean name that uses the class edu.mit.mortar.controller.action.GlobalEntryAction. However, these bean names must be named XXXEntryAction (where XXX is some name you choose), otherwise the session restart mechanism will cause your app to loop infinitely.
The example below is from the oas-skeleton which comes with all new projects set up by the IDD Team. In this example there is a single entry point, /EntryAction, which is configured to chain to the action, EnterSearchCriteria, in the struts-config.xml file.
In addition to this /EntryAction bean, there are an additional 3 beans that correspond to the 3 actions in the oas-skeleton. In order to properly configure your application, you must change these 3 beans to reflect the actions in your application:
For example, the settings001s project action-servlet.xml has 2 actions: 
There is normally a base action class that is injected with the service associated with your application. You can use mock services by overriding this baseAction.
For SAP apps, your base action should be the class edu.mit.mortar.controller.action.SAPBaseAction which is the default taken from the skeleton. So you don't need to make any changes to these lines.
The Search Help actions found in mortar are also configured here. Again you don't need to make any changes unless, in the very rare event, that the current search help functionality found within the mortar jar does not meet your app's needs.
See the JV Suite for an example of the 4.21 mortar search help not meeting the JV Suite Search help needs. Mortar 4.21 search help was designed to automatically bring up the first 500 items in the search if any value was passed to it. Since JV Suite needed to pass company code to an interactive search help, this behavior had to be overridden by creating a replacement SearchHelpNavAction. When this action was created it was configured in the action-servlet.xml: 