Struts Interview Questions and Answers

Answer - 61 : - 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.     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 bu

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

Answer - 63 : - 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: ... ... 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 x.do (i.e. http://localhost:8080/app/x.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. A

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

Answer - 65 : - 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

Answer - 66 : - Another major complaint usually heard amongst Struts 1.0 users is the extensive effort involved in writing the FormBean (a.k.a. ActionForm) classes. Struts provides two-way automatic population between HTML forms and Java objects, the FormBeans. To take advantage of this however, you have to write one FormBean per HTML form. (In some use cases, a FormBean can actually be shared between multiple HTML forms. But those are specific cases.) Struts' FormBean standard follows faithfully the verbose JavaBean standard to define and access properties. Besides, to encourage a maintainable architecture, Struts enforces a pattern such that it is very difficult to 'reuse' a model-layer object (e.g. a ValueObject from the EJB tier) as a FormBean. Combining all these factors, a developer has to spend a significant amount of time to write tedious getters/setters for all the FormBean classes. Struts 1.1 offers an alternative, Dynamic ActionForms, which are based on DynaBeans. Simply put, DynaBeans are type-safe name-value pairs (think HashMaps) but behave like normal JavaBeans with the help of the BeanUtils library. (Both the DynaBeans and the BeanUtils library were found to be useful and generic enough that they have been 'promoted' into Jakarta's Commons project.) With Dynamic ActionForms, instead of coding the tedious setters/getters, developers can declare the required properties in the struts-config.xml files. Struts will instantiate and initialize Dynamic ActionForm objects with the appropriate metadata. From then onwards, The Dynamic ActionForm instance is treated as if it is an ordinary JavaBean by Struts and the BeanUtils library.

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

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

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

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