For web development in j2ee, one needs to know about basic deployment strategy. The 'basic' stuff includes, knowledge of web server and configuration files required by the framework. For servlet/jsp applications web.xml, or deployment descriptor is the key. Production apps have their own framework and come with their own framework (scripts and config files), this is not the objective of this exercise though.
To simplify development, people have been developing utilities. Struts is one such aid. Supported by Apache. This is over and above the basic strategy. Struts dictates that the users provide config file(s). Let us see the various aspects involved in configuration in this blog.
Web.xml
Web.xml is the starting point for any web application. For a struts application the web.xml looks in the following fashion.
<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd">
<servlet>
<servlet-name>action</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>
</init-param>
<init-param>
<param-name>debug</param-name>
<param-value>2</param-value>
</init-param>
<init-param>
<param-name>detail</param-name>
<param-value>2</param-value>
</init-param>
<load-on-startup>2</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>action</servlet-name>
<url-pattern>*.do</url-pattern>
</servlet-mapping>
<session-config>
<session-timeout>
30
</session-timeout>
</session-config>
<welcome-file-list>
<welcome-file>index.jsp</welcome-file>
</welcome-file-list>
<jsp-config>
<taglib>
<taglib-uri>/WEB-INF/struts-bean.tld</taglib-uri>
<taglib-location>/WEB-INF/struts-bean.tld</taglib-location>
</taglib>
<taglib>
<taglib-uri>/WEB-INF/struts-html.tld</taglib-uri>
<taglib-location>/WEB-INF/struts-html.tld</taglib-location>
</taglib>
<taglib>
<taglib-uri>/WEB-INF/struts-logic.tld</taglib-uri>
<taglib-location>/WEB-INF/struts-logic.tld</taglib-location>
</taglib>
<taglib>
<taglib-uri>/WEB-INF/struts-nested.tld</taglib-uri>
<taglib-location>/WEB-INF/struts-nested.tld</taglib-location>
</taglib>
<taglib>
<taglib-uri>/WEB-INF/struts-tiles.tld</taglib-uri>
<taglib-location>/WEB-INF/struts-tiles.tld</taglib-location>
</taglib>
</jsp-config>
</web-app>
|
To understand the above, one needs to have some know how of relation between: servlet-class, servlet-name and servlet-mapping. They are supposed to provide degrees of freedom to various stakeholders namely: the java developer, the server admin or (author of deployment descriptor) and the network admin responsible for url allocation.
All struts applications try to mock front-controller pattern. (A true front controller has no logic what so ever and just delegates, it is left to application designers to come up with the delegators/handlers. In struts 1.xx this is achieved only by using a 'request processor', which is not the default. The delegation logic is held by front-controller in default case. The user can configure the delegation rules). The front-controller is called 'ActionServlet' and is part of struts library. In the above example all urls that match the regex *.do are mapped to this servlet. There are some initialization parameters given to action servlet, the most important of these is the 'config' parameter, we supply struts-config.xml(s) here. Multiple config.xmls are allowed and are comma separated. The config.xmls contain the rules to be followed for request delegation. These are used by ActionServlet.
When a request hits actionservlet, the servlet tries to map it to the appropriate action. Action is a specialised controller. ActionServlet also maps the request parameters to a bean, called as form-bean in struts lingo. By the time request reaches action class, the form-bean gets populated and acts as a data structure. Validation of parameters can be done in the Action class, but the most appropriate location would be form-bean, as per ObjectOriented model. We will see more of struts-config.xml in the next part
Last but not the least are tld definitions provided at the end. These have more to do with jsp tag-libs than struts framework. Think of them as helper classes.
Note
Struts 2 and Spring framework are ideologically more similar than struts 1. In the former, user is allowed to dictate the front-controller (dispatch servlet), user is not forced to extend framework classes. This amounts to greater freedom of design (loose coupling or framework agnostic design). However, how many times did we see an application design change radically?
Posts
