• +91 9971497814
  • info@interviewmaterial.com

Struts Interview Questions Answers

Question 1 : Do ActionForms  have to be true JavaBeans?

Answer 1 : ActionForms are added to a servlet scope (session or request) as beans. What this means is that, for certain functionality to be available, your ActionForms will have to follow a few simple rules. First, your ActionForm bean must have a zero-arguments constructor. This is required because Struts must be able to dynamically create new instances of your form bean class, while knowing only the class name. This is not an onerous restriction, however, because Struts will also populate your form bean's properties (from the request parameters) for you. Second, the fields of your form bean are made available to the framework by supplying public getter and setter methods that follow the naming design patterns described in the JavaBeans Specification. For most users, that means using the following idiom for each of your form bean's properties: private {type} fieldName; public {type} getFieldName() { return (this.fieldName); } public void setFieldName({type} fieldName) { this.fieldName = fieldName; } NOTE - you MUST obey the capitalization conventions shown above for your ActionForm properties to be recognized. The property name in this example is "fieldName", and that must also be the name of the input field that corresponds to this property. A bean property may have a "getter" method and a "setter" method (in a form bean, it is typical to have both) whose name starts with "get" or "set", followed by the property name with the first character capitalized. (For boolean properties, it is also legal to use "is" instead of "get" as the prefix for the getter method.) Advanced JavaBeans users will know that you can tell the system you want to use different names for the getter and setter methods, by using a java.beans.BeanInfo class associated with your form bean. Normally, however, it is much more convenient to follow the standard conventions. WARNING - developers might be tempted to use one of the following techniques, but any of them will cause your property not to be recognized by the JavaBeans introspection facilities, and therefore cause your applications to misbehave: * Using getter and setter method names that do not match - if you have a getFoo() method for your getter, but a setBar() method for your setter, Java will not recognize these methods as r

Question 2 : When is the best time to validate input?

Answer 2 : This is an excellent question. Let's step back a second and think about a typical mid to large size application. If we start from the back end and work toward the view we have: 1) Database: Most modern databases are going to validate for required fields, duplicate records, security constraints, etc. 2) Business Logic: Here you are going to check for valid data relationships and things that make sense for the particular problem you are triing to solve. ... This is where struts comes into the picture, by now the system should be pretty well bulletproof. What we are going to do is make validation friendlier and informative. Rember it is OK to have duplicate validations... 3) ActionErrors validate(ActionMapping map, HttpServletRequest req) is where you can do your validation and feed back to the view, information required to correct any errors. validate is run after the form has been reset and after the ActionForm properties have been set from corresponding view based input. Also remember you can turn validation off with validate="false" in the action mapping in the struts-config.xml. This is done by returning an ActionErrors collection with messages from your ApplicationResources.properties file. Here you have access to the request so you can see what kinds of action is being requested to fine tune your validations. The <html:error> tag allows you to dump all errors on your page or a particular error associated with a particular property. The input attribute of the struts-config.xml action allows you to send validation errors to a particular jsp / html / tile page. 4) You can have the system perform low level validations and client side feedback using a ValidatorForm or its derivatives. This will generate javascript and give instant feedback to the user for simple data entry errors. You code your validations in the validator-rules.xml file. A working knowledge of regular expressions is necessary to use this feature effectively.

Question 3 : What is an “ActionForm”?

Answer 3 : An “ActionForm” is a JavaBean that extends org.apache.struts.action.ActionForm. ActionForm maintains the session state for web application and the “ActionForm” object is automatically populated on the server side with data entered from a form on the client side.  What is Struts Validator Framework? The “Struts Framework” provides the functionality to validate the form data. It can be used to validate the data in the user’s browser as well as on the server side. Struts Framework checks the JavaScript code and it can be used to validate the form data on the client browser. Server side validation of form data can be accomplished by subclassing your “form” Bean with DynaValidatorForm class. The “Validator” framework was developed by David Winterfeldt as a third-party “add-on” to Struts. Now the Validator framework is part of the “Jakarta Commons” project and it can be used with or without Struts. The Validator framework comes integrated with the Struts Framework and can be used without any making any additional settings. Describe the details of XML files used in the “Validator Framework”? The Validator Framework uses two XML configuration files 1) validator-rules.xml and 2) validation.xml. The validator-rules.xml defines the standard validation routines. These are reusable and used in validation.xml to define the form specific validations. The validation.xml defines the validations applied to a form bean.

Question 4 : Direct Requests to JSPs

Answer 4 : 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.

Question 5 : What is an “Action Class”?

Answer 5 : The “Action Class” is part of the “Model” and is a wrapper around the business logic. The purpose of the “Action Class” is to translate the HttpServletRequest to the business logic. To use the “Action”, we need to subclass and overwrite the execute() method. All the database and business processing is done in the “Action” class. It is advisable to perform all the database related work in the “Action” class. The ActionServlet (command) passes the parameterized class to ActionForm using the execute() method. The return type of the execute method is ActionForward which is used by the Struts Framework to forward the request to the file according to the value of the returned ActionForward object.

Question 6 : Action.execute() and Action.getResources()

Answer 6 : 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.

Question 7 : Validator

Answer 7 : 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 it here. 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 the client-side validation code (i.e. Javascript) from the same set of 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.

Question 8 : Default Sub-application

Answer 8 : 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 sub-application.

Question 9 : Why are some of the class and element names counter-intuitive?

Answer 9 : The framework grew in the telling and, as it evolved, some of the names drifted. The good thing about a nightly build, is that everything becomes available to the community as soon as it is written. The bad thing about a nightly build is that things like class names get locked down early and then become difficult to change.

Question 10 : Why doesn't the focus feature on the <html:form> tag work in every circumstance?

Answer 10 : Unfortunately, there is some disagreement between the various browsers, and different versions of the same browser, as to how the focus can be set. The <html:form> tag provides a quick and easy JavaScript that will set the focus on a form for most versions of most browsers. If this feature doesn't work for you, then you should set the focus using your own JavaScript. The focus feature is a convenient "value-add" -- not a core requirement of the tag. If you do come up with a JavaScript that provides the final solution to this project, please post your patch to this Bugzilla ticket.

Struts Contributors


Share your email for latest updates


Our partners