The same logic that is in the RequestProcessor class can be written in the ActionServlet, but if we want to override any of the methods in the ActionServlet then our class should extend the ActionServlet to override those methods for our specific behaviour. In that case our class will become the Controller not the ActionServlet. For this reason the customisation logic is moved to a separate class called RequestProcessor instead of giving the chance to the user to configure his own Controller.
If we want any specific behaviour, override the methods of the RequestProcessor and give our own class entry in the <controller /> tag of the “struts-config.xml”. When the container reads the xml file it checks weather the there is any <controller /> in the struts-config.xml, if there is an entry in the config file it means that the RequestProcessor class is overridden and the container creates the object for that class instead of RequestProcessor class. There should be only one RequestProcessor object for an application.
Internally, struts creates the the RequestProcessor object and keeps it in the HashMap. For the first request there will be null in the HashMap, once it creates the object, then it keeps the object in the HashMap, then for the further requests it checks for the object in the HashMap and if its null it creates the object.
For the first request usually there will be null in the HashMap. The problem occurs when the second request comes after the object is created and before the object is set in the HashMap for the very first request. When the second request comes still there will be null in the HashMap as the object is not set yet. So the container creates the object for the second request also and tries to set the object in the HashMap. But at anytime there should be one and only one RequestProcessor object for an application. To avoid this situation, internally the object creation process is done in a “synchronised method”.
In this situation when the first request comes the RequestProcessor object is created and is set into the Hashmap. For further requests the container checks the HashMap and it finds the object so it uses the same object rather than creating a new object for each and every request. **
If we want any specific behaviour, override the methods of the RequestProcessor and give our own class entry in the <controller /> tag of the “struts-config.xml”. When the container reads the xml file it checks weather the there is any <controller /> in the struts-config.xml, if there is an entry in the config file it means that the RequestProcessor class is overridden and the container creates the object for that class instead of RequestProcessor class. There should be only one RequestProcessor object for an application.
Internally, struts creates the the RequestProcessor object and keeps it in the HashMap. For the first request there will be null in the HashMap, once it creates the object, then it keeps the object in the HashMap, then for the further requests it checks for the object in the HashMap and if its null it creates the object.
For the first request usually there will be null in the HashMap. The problem occurs when the second request comes after the object is created and before the object is set in the HashMap for the very first request. When the second request comes still there will be null in the HashMap as the object is not set yet. So the container creates the object for the second request also and tries to set the object in the HashMap. But at anytime there should be one and only one RequestProcessor object for an application. To avoid this situation, internally the object creation process is done in a “synchronised method”.
In this situation when the first request comes the RequestProcessor object is created and is set into the Hashmap. For further requests the container checks the HashMap and it finds the object so it uses the same object rather than creating a new object for each and every request. **
