Struts has a filter dispatcher similar to that in Hello World! application. Its fully qualified name is org.apache.struts2.dispatcher.FilterDispatcher. To use it, register it in the deployment descriptor (WEB.XML file) using this filter and filter-mapping elements.
<filter>
<filter-name>struts2</filter-name>
<filter-class>
org.apache.struts2.dispatcher.FilterDispatcher
</filter-class>
</filter>
<filter-name>struts2</filter-name>
<filter-class>
org.apache.struts2.dispatcher.FilterDispatcher
</filter-class>
</filter>
<filter-mapping>
<filter-name>struts2</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
<filter-name>struts2</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>
There's a lot that a filter dispatcher in a Model 2 application has to do and Struts' filter dispatcher is by no means an exception. Since Struts has more, actually much more, features to support, its filter dispatcher could grow infinitely in complexity. However, Struts approaches this by splitting task processing in its filter dispatcher into subcomponents called interceptors. The first interceptor you'll notice is the one that populates the action object with request parameters.
In a Struts application the action method is executed after the action's properties are populated. An action method can have any name as long as it is a valid Java method name.
FilterDispatcher finds that if any action require to execute at the initial phase, if require it will invoke the action, otherwise, it will move control to index page of the application.
The first things that a filter dispatcher does is verify the request URI and determine what action to invoke and which Java action class to instantiate. The filter dispatcher in Hello World! did this by using a string manipulation method. However, this is impractical since during development the URI may change several times and you will have to recompile the filter each time the URI or something else changes.
For matching URIs with action classes, Struts uses a configuration file named struts.xml.
Basically, you need to create a struts.xml file and place it under WEB-INF/classes. You define all actions in the application in this file. Each action has a name that directly corresponds to the URI used to invoke the action. Each action declaration may specify the
fully qualified name of an action class, if any. You may also specify the action method name unless its name is execute, the default method name Struts will assume in the absence of an explicit one.
An action class must have at least one result to tell Struts what to do after it executes the action method. There may be multiple results if the action method may return different results depending on, say, user inputs.
The struts.xml file is read when Struts starts. In development mode, Struts checks the timestamp of this file every time it processes a request and will reload it if it has changed since the last time it was loaded. As a result, if you are in development mode and you change the struts.xml file, you don't need to restart your web container. Saving you time. Configuration file loading will fail if you don't comply with the rules that govern the struts.xml file. If, or should I say when, this happens, Struts will fail to start and you must restart your container. Sometimes it's hard to decipher what you've done wrong due to unclear error messages. If this happens, try commenting out actions that you suspect are causing it, until you isolate and fix the one that is impending development.
In a Struts application the action method is executed after the action's properties are populated. An action method can have any name as long as it is a valid Java method name.
FilterDispatcher finds that if any action require to execute at the initial phase, if require it will invoke the action, otherwise, it will move control to index page of the application.
The first things that a filter dispatcher does is verify the request URI and determine what action to invoke and which Java action class to instantiate. The filter dispatcher in Hello World! did this by using a string manipulation method. However, this is impractical since during development the URI may change several times and you will have to recompile the filter each time the URI or something else changes.
For matching URIs with action classes, Struts uses a configuration file named struts.xml.
Basically, you need to create a struts.xml file and place it under WEB-INF/classes. You define all actions in the application in this file. Each action has a name that directly corresponds to the URI used to invoke the action. Each action declaration may specify the
fully qualified name of an action class, if any. You may also specify the action method name unless its name is execute, the default method name Struts will assume in the absence of an explicit one.
An action class must have at least one result to tell Struts what to do after it executes the action method. There may be multiple results if the action method may return different results depending on, say, user inputs.
The struts.xml file is read when Struts starts. In development mode, Struts checks the timestamp of this file every time it processes a request and will reload it if it has changed since the last time it was loaded. As a result, if you are in development mode and you change the struts.xml file, you don't need to restart your web container. Saving you time. Configuration file loading will fail if you don't comply with the rules that govern the struts.xml file. If, or should I say when, this happens, Struts will fail to start and you must restart your container. Sometimes it's hard to decipher what you've done wrong due to unclear error messages. If this happens, try commenting out actions that you suspect are causing it, until you isolate and fix the one that is impending development.
No comments:
Post a Comment