The Validator is not exactly a new feature. The Validator has been in
the contrib package in the distribution since Struts 1.0.1. Since then,
part of it has now been refactored and moved into the Jakarta-Commons
subproject and renamed the Commons-Validator and the Struts specific
portion is now called the Struts-Validator. However, since it is in the
contrib package, people may overlook it and it is worthwhile to mention
The Validator provides an extensible framework to define validation
rules to validate user inputs in forms. What is appealing in the
Validator is that it generates both the server-side validation code and
validation rules defined in an XML configuration file. The Validator
performs the validation based on regular-expression pattern matching.
While a handful of commonly used validators are shipped with the
framework (e.g. date validator, range validator), you can always define
your own ones to suit your need.
To maintain backward compatibility, Struts 1.1 allows one default
sub-application per application. The URI of the resources (i.e. JSPs,
HTMLs, etc) in the default sub-application will have an empty sub-app
prefix. This means when an existing 1.0 application is "dropped" into
Struts 1.1, theoretically, it will automatically become the default
Direct Requests to JSPs
To take the full advantage of sub-application support, Struts 1.1
stipulates the requirement that all requests must flow through the
controller servlet, i.e. the ActionServlet. Effectively, this means all
JSPs must be fronted by Actions. Instead of allowing direct requests to
any of the JSPs, all requests must go through an Action and let the
Action forward to the appropriate JSP.
This is perhaps the biggest impact of migration to Struts 1.1 if you
have not followed this idiom in your applications. This restriction is
required because without going through the ActionServlet, Struts
navigation taglibs (e.g. <html:form> and <html:link>) used in the JSPs
will not have the correct sub-app context to work with.
With the introduction of sub-applications, a more flexible way is
introduced to configure each sub-application independently. Many of the
configuration entries (e.g. resource bundle location, maximum upload
file size, etc) that used to be defined in web.xml have now been moved
to struts-config.xml. The original entries in web.xml are deprecated but
will still be effective.
Action.execute() and Action.getResources()
In Struts 1.0, request handling logic is coded in Action.perform();
however, Action.perform() throws only IOException and SevletException.
To facilitate the new declarative exception handling , the request
handling method needs to throw Exception, the superclass of all the
checked exceptions. Therefore, to both maintain backward compatibility
and facilitate declarative exception handling, Action.perform() is now
deprecated in favour of Action.execute().
You also have to be careful if you use DispatchAction in your existing
applications. At the time of writing, the DispatchAction in Struts 1.1
beta has not yet been updated to use execute(). (A bug report has been
filed in Struts' bug database.) Therefore, without modifying the
DispatchAction class yourself, declarative exception handling will not
work with DispatchAction subclasses.
In addition, Action.getResources() is now deprecated. Instead, you
should call Action.getResources(HttpServletRequest) instead. This allows
Struts to return to you the sub-application specific message resources.
Otherwise, the message resources for the default sub-app will be used.
Struts 1.1 now depends on a handful of libraries from other Jakarta
subprojects (e.g. Commons-Logging, Commons-Collections, etc.). Some of
these libraries may cause classloading conflicts in some servlet
containers. So far, people have reported in the mailing list the
classloading problem of commons-digester/jaxp1.1, and commons-logging
causing deployment difficulties in Struts 1.1 applications running on
Weblogic 6.0. (The problems have been corrected in Weblogic 6.1 and
Resources under WEB-INF
According to the Servlet specification, resources (e.g. JSP files)
stored under WEB-INF are protected and cannot be accessed directly by
the browsers. One design idiom for Struts 1.0 is to put all the JSP
files under WEB-INF and front them by Actions so that clients cannot
illegally access the JSPs. With the introduction of sub-application
prefixes in Struts 1.1, mapping resources under WEB-INF gets
complicated. Extra configuration steps utilizing the pagePattern and
forwardPattern attributes of the element in struts-config.xml is
required to inform Struts to construct the paths correctly. More
specifically, you need to set these attributes to the pattern
What is the Jakarta Struts Framework?
Jakarta Struts is an open source implementation of MVC
(Model-View-Controller) pattern for the development of web based
Jakarta Struts is a robust architecture and can be used for the
development of applications of any size.
The “Struts framework” makes it easier to design scalable, reliable Web
What is an ActionServlet?
The class org.apache.struts.action.ActionServlet is called the
In the Jakarta Struts Framework this class plays the role of controller.
All the requests to the server go through the “Controller”.
The “Controller” is responsible for handling all the requests.
How can one make any “Message Resources” definitions file
available to the “Struts Framework” environment?
Answer: “Message Resources” definitions file are simple .properties
these files contain the messages that can be used in the struts project.
“Message Resources” definition files can be added to the struts-config.xml
through <message-resources /> tag. Example:
<message-resources parameter="MessageResources" />