Struts Interview Questions and Answers
Ques 66. 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?
Ans. 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 67. 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.Ans. 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.
Ques 68. Multiple Sub-applicationsAns. One of the shortcomings in Struts 1.0 is manageability of the configuration file (commonly known as struts-config.xml) when the development of the application involves a sizable team. This problem arises because a Struts-based application must run under one controller servlet, the ActionServlet, and the ActionServlet can use only one struts-config.xml. It is not an issue when the project is relatively small and the team consists of a couple of developers; however, when the project size becomes significant and the project involves a large number of developers, maintaining all the mapping information in a single file becomes increasingly problematic.
Struts 1.1 solves this problem nicely by introducing multiple sub-applications. In Struts 1.1, each sub-application has its own struts-config.xml file. A large Struts-based application can thus be easily partitioned into largely independent modules, i.e. sub-applications, and each sub-team can maintain their struts-config.xml independently.
The sub-application scheme is a natural extension of the servlet context mapping scheme of the URI paths used by servlet containers. According to the Servlet standard, when the servlet container receives a request with a URL, the servlet container will try to match the prefix of the URI path to a deployed web-application in the container. What Struts 1.1 does is it maps the second prefix of the path to a sub-application. In effect, this prefix mapping scheme creates another level of namespace for each sub-application. For example, for the URI,
/myApp is the context path for a web-application called "myApp" and /module2 is the sub-app prefix for a Struts sub-application called "module2".
Ques 69. DynaBean and BeanUtilsAns. 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.
Ques 70. Explain Validator in Struts.Ans. 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.
Most helpful rated by users: