Struts Interview Questions and Answers
Experienced / Expert level questions & answers
Ques 1. Why it called Struts?
Because the designers want to remind us of the invisible underpinnings that hold up our houses, buildings, bridges, and ourselves when we are on stilts. This excellent description of Struts reflect the role the Struts plays in developing web applications.
Ques 2. Is Struts efficient?
The Struts is not only thread-safe but thread-dependent(instantiates each Action once and allows other requests to be threaded through the original object.
ActionForm beans minimize subclass code and shorten subclass hierarchies
The Struts tag libraries provide general-purpose functionality
The Struts components are reusable by the application
The Struts localization strategies reduce the need for redundant JSPs
The Struts is designed with an open architecture--subclass available
The Struts is lightweight (5 core packages, 5 tag libraries)
The Struts is open source and well documented (code to be examined easily)
The Struts is model neutral
Ques 3. Why do we need Struts?
Java technologies give developers a serious boost when creating and maintaining applications to meet the demands of today's public Web sites and enterprise intranets. Struts combines Java Servlets, Java ServerPages, custom tags, and message resources into a unified framework. The end result is a cooperative, synergistic platform, suitable for development teams, independent developers, and everyone in between.
Ques 4. Why is it called Struts?
It's a reference to struts in the architectural sense, a reminder of the nearly invisible pieces that hold up buildings, houses, and bridges.
Ques 5. Do I have to credit Struts on my own website?
You need to credit Struts if you redistribute your own framework based on Struts for other people to use. (See the Apache License for details.) But you do not need to credit Struts just because your web application utilizes the framework. It's the same situation as using the Apache HTTPD server or Tomcat. Not required if its just running your web site.
Ques 6. Where can I get a copy of Struts?
The best place to download Struts is at struts.apache.org. The nightly builds are very stable, and recommended as the best place to start today.
Ques 7. If the framework doesn't do what I want, can I request that a feature be added?
First, it's important to remember that Struts is an all-volunteer project. We don't charge anyone anything to use Struts. Committers and other developers work on Struts because they need to use it with their own applications. If others can use it too, that's "icing on the cake". If you submit a patch for a feature that a Committer finds useful, then that Committer may choose to volunteer his or her time to apply the patch. If you just submit an idea without a patch, it is much less likely to be added (since first someone else has to volunteer their time to write the patch).
We are grateful for any patches, and we welcome new ideas, but the best way to see that something gets added to the framework is to do as much of the work as you can, rather than rely on the "kindness of strangers". Worst case, you can apply the patch to your copy of Struts and still use the feature in your own application. (Which is what open source is ~really~ all about.)
Ques 8. Will the Struts tags support other markup languages such as WML ?
Struts itself is markup neutral. The original Struts taglibs are only one example of how presentation layer components can access the framework. The framework objects are exposed through the standard application, session, and request contexts, where any Java component in the application can make use of them.
Markup extensions that use Struts are available for Velocity and XLST, among others. A new Struts tag library for Java Server Faces is also in development.
For more about using WAP/WML with Struts see the article WAP up your EAserver.
Ques 9. Why was reload removed from Struts (since 1.1)?
The problem with ReloadAction was that Struts was trying to act like a container, but it couldn't do a proper job of it. For example, you can't reload classes that have been modified, or (portably) add new classes to a running web application (even if the container supported it).
Meanwhile, as Struts 1.1 was being developed, work progressed on things like Tomcat's reload command via the Manager webapp. This feature allows you to quickly reload-on-demand, complete with saving and restoring your session). It started to make even less sense for Struts to half-implement a feature that containers are implementing fully.
A more minor point is that freezing the configuration information at application startup time allows Struts to safely access the mapping information without bothering with synchronization. The "startup-only" strategy creates a modest but real improvement in performance for all users.
So, ReloadAction is not supported since Struts 1.1 for two reasons:
* It never did let you reload everything that you would really want to -- particularly changed classes -- so many people ended up having to reload the webapp anyway.
* Containers are starting to offer reload-on-demand features which does the same thing as the Struts ReloadAction, only better.
* Not supporting ReloadAction lets Struts avoid doing synchronization locks around all the lookups (like figuring out which action to use, or the destination of an ActionForward) so applications can run a little faster.
Of course, if someone came up with an implementation that solved these problems without creating any others, we would not be opposed to including a new ReloadAction.
Ques 10. What is a modular application? What does module-relative mean?
Since Struts 1.1, the framework supports multiple application modules. All applications have at least one root, or default, module. Like the root directory in a file system, the default application has no name. (Or is named with an empty string, depending your viewpoint.) Developing an application with only a default module is no different from how applications were developed under Struts 1.0. Since Struts 1.1, you can add additional modules to your application, each of which can have their own configuration files, messages resources, and so forth. Each module is developed in the same way as the default module. Applications that were developed as a single module can added to a multiple module application, and modules can promoted to a standalone application without change. For more about configuring your application to support multiple modules, see Configuring Applications in the User Guide.
But to answer the question =:0), a modular application is a Struts application that uses more than one module. Module-relative means that the URI starts at the module level, rather than at the context level, or the absolute-URL level.
* Absolute URL: http://localhost/myApplication/myModule/myAction.do
* context-relative: /myModule/myAction.do
* module-relative: /myAction.do
The Struts Examples application is a modular application that was assembled from several applications that were created independently.
Ques 11. Why are some of the class and element names counter-intuitive?
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.
Ques 12. Why is ActionForm a base class rather than an interface?
The MVC design pattern is very simple to understand but much more difficult to live with. You just need this little bit of Business Logic in the View logic or you need just that little bit of View logic in the Business tier and pretty soon you have a real mess.
Making ActionForm a class takes advantage of the single inheritance restriction of Java to it makes it more difficult for people to do things that they should not do.
ActionForms implemented as interfaces encourage making the property types match the underlying business tier instead of Strings, which violates one of the primary purposes for ActionForms in the first place (the ability to reproduce invalid input, which is a fundamental user expectation). ActionForms as an interface would also encourage using existing DAO objects as ActionForms by adding 'implements ActionForm' to the class. This violates the MVC design pattern goal of separation of the view and business logic.
Since the goal of struts is to enforce this separation, it just makes more sense for Struts to own the ActionForm.
DynaActionForms relieve developers of maintaining simple ActionForms. For near zero maintenance, try Niall Pemberton's LazyActionForm
Ques 13. Why doesn't the focus feature on the <html:form> tag work in every circumstance?
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.
Ques 14. Can't I just create some of my JavaBeans in the JSP using a scriptlet?
Struts is designed to encourage a Model 2/MVC architecture. But there is nothing that prevents you from using Model 1 techniques in your JavaServer Pages, so the answer to the question is "Yes, you can".
Though, using Model 1 techniques in a Struts application does go against the grain. The approach recommended by most Struts developers is to create and populate whatever objects the view may need in the Action, and then forward these through the request. Some objects may also be created and stored in the session or context, depending on how they are used.
Likewise, there is nothing to prevent you from using scriptlets along with JSP tags in your pages. Though, many Struts developers report writing very complex scriplet-free applications and recommend the JSP tag approach to others.
For help with Model 1 techniques and scriptlets, you might consider joining the Javasoft JSP-interest mailing list, where there are more people still using these approaches.
Ques 15. How do I use JavaScript to struts?
.
Struts is mainly a server-side technology. We bundled in some JSP tags to expose the framework components to your presentation page, but past that, the usual development process applies.
Interactive pages require the use of JavaScript. (That's why it was invented.) If you want things popping up or doing this when they click that, you are outside the scope of Struts and back into the web development mainstream.
You use JavaScript with Struts the same way you use with any presentation page. Since JavaScript is a client-side technology, you can use simple relative references to your scripts. If you need to fire a JavaScript from a HTML control, the Struts HTML tags have properties for the JavaScript events.
A very good JavaScript resource is Matt Kruse's site at http://www.mattkruse.com/javascript/ Do I need to implement reset and set all my form properties to their initial values?
No. You need to set checkbox properties to false if the ActionForm is being retained in session scope. This is because an unchecked box does not submit an attribute. Only checked boxes submit attributes. If the form is in session scope, and the checkbox was checked, there is no way to turn it back off without the reset method. Resetting the properties for other controls, or for a request scope form, is pointless. If the form is in request scope, everything already just started at the initial value.
Ques 16. Can I use other beans or hashmaps with ActionForms?
Yes. There are several ways that you can use other beans or hashmaps with ActionForms.
* ActionForms can have other beansor hashmaps as properties
* "Value Beans" or "Data Transfer Objects" (DTOs) can be used independently of ActionForms to transfer data to the view
* ActionForms can use Maps to support "dynamic" properties (since Struts 1.1)
ActionForms (a.k.a. "form beans") are really just Java beans (with a few special methods) that Struts creates and puts into session or request scope for you. There is nothing preventing you from using other beans, or including them in your form beans. Here are some examples:
Collections as properties Suppose that you need to display a pulldown list of available colors on an input form in your application. You can include a string-valued colorSelected property in your ActionForm to represent the user's selection and a colorOptions property implemented as a Collection (of strings) to store the available color choices. Assuming that you have defined the getters and setters for the colorSelected and colorOptions properties in your orderEntryForm form bean, you can render the pulldown list using:
<html:select property="colorSelected">
<html:options property="colorOptions" name="orderEntryForm"/>
</html:select>
The list will be populated using the strings in the colorOptions collection of the orderEntryForm and the value that the user selects will go into the colorSelected property that gets posted to the subsequent Action. Note that we are assuming here that the colorOptions property of the orderEntryForm has already been set.
See How can I prepopulate a form? for instructions on how to set form bean properties before rendering edit forms that expect properties to be pre-set.
Independent DTO An Action that retrieves a list of open orders (as an ArrayList of Order objects) can use a DTO independently of any form bean to transfer search results to the view. First, the Action's execute method performs the search and puts the DTO into the request:
ArrayList results = businessObject.executeSearch(searchParameters);
request.setAttribute("searchResults",results);
Then the view can iterate through the results using the "searchResults" request key to reference the DTO:
` <logic:iterate id="order" name="searchResults" type="com.foo.bar.Order">
<tr><td><bean:write name="order" property="orderNumber"/><td>
<td>..other properties...</td></tr>
</logic:iterate>
Ques 17. How can I scroll through list of pages like the search results in google?
Many Struts developers use the Pager from the JSPTags site.
http://jsptags.com/tags/navigation/pager/
Ques 18. Why does the <html:link> tag URL-encode javascript and mailto links?
The <html:link> tag is not intended for use with client-side references like those used to launch Javascripts or email clients. The purpose of link tag is to interject the context (or module) path into the URI so that your server-side links are not dependent on your context (or module) name. It also encodes the link, as needed, to maintain the client's session on the server. Neither feature applies to client-side links, so there is no reason to use the <html:link> tag. Simply markup the client-side links using the standard tag.
Ques 19. How can I avoid validating a form before data is entered?
The simplest way is to have two actions. The first one has the job of setting the form data, i.e. a blank registration screen. The second action in our writes the registration data to the database. Struts would take care of invoking the validation and returning the user to the correct screen if validation was not complete.
The EditRegistration action in the struts example application illustrates this:
< action path="/editRegistration">
type="org.apache.struts.webapp.example.EditRegistrationAction"
attribute="registrationForm"
scope="request"
validate="false">
When the /editRegistration action is invoked, a registrationForm is created and added to the request, but its validate method is not called. The default value of the validate attribute is true, so if you do not want an action to trigger form validation, you need to remember to add this attribute and set it to false.
Ques 20. How can I create a wizard workflow?
The basic idea is a series of actions with next, back, cancel and finish actions with a common bean. Using a LookupDispatchAction is reccomended as it fits the design pattern well and can be internationalized easily. Since the bean is shared, each choice made will add data to the wizards base of information. A sample of struts-config.xml follows:
< form-beans>
<form-bean name="MyWizard"
type="forms.MyWizard" />
</form-beans>
<!-- the first screen of the wizard (next action only available) -->
<!-- no validation, since the finish action is not available -->
<actions>
<action path="/mywizard1"
type="actions.MyWizard"
name="MyWizard"
validate="false"
input="/WEB-INF/jsp/mywizard1.jsp">
<forward name="next"
path="/WEB-INF/jsp/mywizard2.jsp" />
<forward name="cancel"
path="/WEB-INF/jsp/mywizardcancel.jsp" />
</action>
<!-- the second screen of the wizard (back, next and finish) -->
<!-- since finish action is available, bean should validated, note
validation should not necessarily validate if back action requested, you
might delay validation or do conditional validation -->
<action path="/mywizard2"
type="actions.MyWizard"
name="MyWizard"
validate="true"
input="/WEB-INF/jsp/mywizard2.jsp">
<forward name="back"
path="/WEB-INF/jsp/mywizard1.jsp" />
<forward name="next"
path="/WEB-INF/jsp/mywizard3.jsp" />
<forward name="finish"
path="/WEB-INF/jsp/mywizarddone.jsp" />
<forward name="cancel"
path="/WEB-INF/jsp/mywizardcancel.jsp" />
</action>
<!-- the last screen of the wizard (back, finish and cancel only) -->
<action path="/mywizard3"
type="actions.MyWizard"
name="MyWizard"
validate="true"
input="/WEB-INF/jsp/mywizard3.jsp">
<forward name="back"
path="/WEB-INF/jsp/mywizard2.jsp" />
<forward name="finish"
path="/WEB-INF/jsp/mywizarddone.jsp" />
<forward name="cancel"
path="/WEB-INF/jsp/mywizardcancel.jsp" />
</action>
The pieces of the wizard are as follows:
forms.MyWizard.java - the form bean holding the information required
actions.MyWizard.java - the actions of the wizard, note the use of LookupDispatchAction allows for one action class with several methods. All the real work will be done in the 'finish' method.
mywizard[x].jsp - the data collection jsp's
mywizarddone.jsp - the 'success' page
mywizardcancel.jsp - the 'cancel' page
Ques 21. What's the best way to deal with migrating a large application from Struts to JSF? Is there any tool support that can help?
This is a complicated task depending on your Struts application. Because the two frameworks have different goals, there are some challenges. Migrate your response pages first. Keep the Struts controller and place and forward to JSF pages. Then you can configure Struts forwards to go through the Faces servlet. Consider looking at the Struts-Faces framework from Apache. See the framework chapter in JSF in Action.
Ques 22. How can I 'chain' Actions?
Chaining actions can be done by simply using the
proper mapping in your forward entries in the struts-config.xml file.
Assume you had the following two classes:
/* com/AAction.java */
...
public class AAction extends Action
{
public ActionForward
execute(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws
Exception
{
// Do something
return mapping.findForward("success");
}
}
/* com/BAction.java */
...
public class BAction extends Action
{
public ActionForward
execute(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response) throws
Exception
{
// Do something else
return mapping.findForward("success");
}
}
Then you can chain together these two actions with
the Struts configuration as shown in the following excerpt:
...
validate="false">
scope="session"
validate="false">
...
Here we are assuming you are using a suffix-based (.do) servlet mapping, which is recommended since module support requires it. When you send your browser to the web application and name the action A.do (i.e. http://localhost:8080/app/A.do) it will execute AAction.execute(), which will then forward to the "success" mapping.
This causes the execution of BAction.execute() since the entry for "success" in the configuration file uses the .do suffix.
Of course it is also possible to chain actions programmatically, but the power and ease of being able to "reroute" your web application's structure using the XML configuration file is much easier to maintain.
As a rule, chaining Actions is not recommended. If your business classes are properly factored, you should be able to call whatever methods you need from any Action, without splicing them together into a cybernetic Rube Goldberg device.
If you must chain Actions, be aware of the following: calling the second Action from the first Action has the same effect as calling the second Action from scratch. If both of your Actions change the properties of a formbean, the changes made by the first Action will be lost because Struts calls the reset() method on the formbean when the second Action is called.
Ques 23. Struts GenericDataSource Just a general question - I'm building an application that will run stand-alone, not in an application server. I need to manage some database connections. Is the struts GenericDataSource a good candidate to do this for me? I basicly just need a connection pool from where I can get connections and then return them to optimize performance.
If this struts class is not a good candidate, can someone recommend a similar pool-manager that is lean and mean and easy to use?
Answer 1
The Struts 1.0 GenericDataSource is not a good candidate for a production server. In Struts 1.1, the Commons DBCP is used istead, which is a good candidate for a production server. (You can also use the DBCP in Struts 1.0 by specifying the type and including the Commons JARs.)
Another popular choice is Poolman. It's not under active development, but I believe you can still download it from SourceForge. Poolman is also very easy to use outside of Struts.
Many containers also offer support for connection pools. The one that ships with Resin is quite good. The later versions of Tomcat bundle the Commons DBCP.
Regardless of what pool you use, a good practice is to hide it behind some type of adaptor class of your own (often a singleton), to make it easy to change later. So your classes call your adaptor, and your adaptor calls whichever pool you are using.
A neat and often-overlooked aspect of the Struts DataSource manager is that it supports loading multiple connection pools and giving each a name. So you might have one pool for internal use and another for public use. This way, the public connections can't swap your administrative access to the application. Each pool could also have its own login, and therefore different rights to the underlying database.
Answer 2
int i=1;
with Struts 1.0 and jdbc i'am use GenericDataSource
not in struts-xml, but in Client.properties
my Client.properties
instanceBd=oraID
userPasswd=xxx/yyyy
maxCount=20
minCount=19
port=1521
driver=oracle.jdbc.driver.OracleDriver
url=jdbc:oracle:thin:@serverName:port:instanceBd
then, on my code i have init (struts 1.0 or struts 1.1):
GenericDataSource ng = new GenericDataSource ();
ng.setUser (mprop.getUserBd());
ng.setPassword (mprop.getPasswdBd());
ng.setUrl (mprop.getUrl());
ng.setDriverClass(mprop.getDriverClass());
ng.setMaxCount(mprop.getMaxCount());
ng.setMinCount (mprop.getMinCount());
ng.setDescription("jdbc OracleDriver");
ng.setAutoCommit(true);
try { ng.open(); } catch (java.sql.SQLException e) {
}
in business logic (or pool) :
Connect cn = ng.getConnection();
it's work.
with struts 1.1 , struts-legacy.jar is necessy for this codes.
it's work.
Ques 24. Is it possible to create the elements of a page(jsp) dynamically based on the results of a data base query, when using struts framework?
If you are talking about rendering a report, then sure. The Action iteracts with the business layer/data access objects to acquire the data, and then passes it to the presentation page bundled up as a JavaBean or a collection of JavaBeans. The JSP tags (and other systems) all use reflection, so you can use whatever JavaBean you like.
If you are talking about creating a dynamic data-entry form, then "not so much".
Struts 1.1 supports map-backed ActionForms, but the page still needs to know what input fields are going to be needed. For a truly dynamic input form, I guess the key would be some type of tag that took a map and then generated a column of input fields. (Wouldn't work for everyone, since a lot of forms must be designed just so.) For extra credit, the entry names could (optionally) be resource keys that were used to find the label text.
Text fields would be easy. Others would need some type of JavaBean with properties to tell the tag what to output. A bit of work, but obviously doable.
Of course, you'd probably want to validate the form before passing it back to the database. I imagine it's possible to use the validator in a non-declarative way, but I don't know anyone whose doing that. If you can do a db query to get the information about the form, I imagine you could also do a query to get the information about validations for the form. It would probably be easier to write your own engine than adopt the validator. (It's not really that complicated to do.)
People often ask about "dynamic input forms", but most of us just can't get our head around the use case. It's hard to understand what you do with the dynamic data when it comes back. Most application don't allow you to input or update an arbitrary (e.g. dynamic) set of fields.
Ques 25. Both JSF and Struts will continue to exist for a while. The Struts community is aware of JSF and is positioning itself to have strong support for JSF. See What about JSTL and JavaServer faces?
From a tools perspective, if you look at the support for JSF versus Struts in WebSphere Studio, the Struts tools are focused around the controller aspects. The Web Diagram editor helps build your Struts configuration and the wizards/editors build Struts artifacts. The JSF tools are geared towards building pages, and in essence, hide the JSF framework from you. Expect WebSphere Studio to support both frameworks for a while. As JSF matures, expect to see some of the controller aspects in JSF to become toolable.
Ques 26. Can you compare the advantages and disadvantages of JSF vs. Struts. Both now, and from what you may know of futures, how and if JSF will evolve into a superior technology vs. Struts? Include how WSAD plays into the comparison if it will help differentiate the two.
This is a very popular question these days. In general, JSF is still fairly new and will take time to fully mature. However, I see JSF being able to accomplish everything Struts can, plus more. Struts evolved out of necessity. It was created by developers who were tired of coding the same logic again and again. JSF emerged both from necessity and competition.
Struts has several benefits:
* Struts is a mature and proven framework. It has been around for a few years and deployed successfully on many projects. The WebSphere Application Server admin console is a Struts application.
* Struts uses the Front Controller and Command patterns and can handle sophisticated controller logic.
* In addition to the core controller function, it has many add-on benefits such as layouts with Tiles, declarative exception handling, and internationalization.
There are disadvantages:
* Struts is very JSP-centric and takes other frameworks to adapt to other view technologies.
* Although Struts has a rich tag library, it is still geared towards helping the controller aspect of development and does not give a sense that you are dealing with components on a page. Therefore, it is not as toolable from a view perspective.
* Struts requires knowledge of Java?. Its goal was to aid Java developers, but not to hide Java. It does not hide details of the Java language to Web developers that well.
* ActionForms are linked programmatically to the Struts framework. Therefore, to decouple the model, you need to write transfer code or use utilities to move data from Action Forms to the Model on input.
JSF is an evolution of a few frameworks, including Struts. The creator of Struts, Craig McClanahan, is one of the JSF specification leads. Therefore, it is not by accident to see some overlap between Struts and JSF. However, one of JSF's major goals is to help J2EE Web applications to be easily developed using RAD tools. As such, it introduces a rich component model. JSF has several advantages:
* JSF is a specification from Sun® and will be included in future versions of the J2EE specification. All major vendors are pledging strong support for JSF.
* JSF uses the Page Controller Pattern and therefore aids in Page rich applications. Components can respond to event from components on a page.
* JSF has a well-defined request lifecycle allowing for plugability at different levels.
* One powerful example of plugability is building your own render toolkit. The ability to separate the rendering portion from the controller portion of the framework allows for wonderful opportunities of extensibility. Component providers can write their own toolkits to render different markup languages, such as XML or WML. In addition, the render toolkit is not tied to JSP.
* Because JSF has a rich component model, it favors a RAD style of development. I can now build my Web pages using drag and drop technology. In addition, JSF gives me a way to link visual components to back model components without breaking the layering.
JSF has disadvantages:
* JSF is still quite new and evolving. It will take some time to see successful deployments and wide usage. In addition, as vendors write components, they may not do everything you want them to.
* JSF by hand is not easier than Struts. Its goal was more oriented to RAD. Those who prefer to do things by hand (for example, the vi type guy who does not like IDEs) may find Struts easier to develop.
* Struts navigation may be a bit more flexible and adhere to more complex controller logic.
Most helpful rated by users:
- What is Struts?
- What helpers in the form of JSP pages are provided in Struts framework?
- How is the MVC design pattern used in Struts framework?
- Who makes the Struts?
- Why it called Struts?