• +91 9971497814
  • info@interviewmaterial.com

Computer Interview Questions Answers

Struts Interview Questions Answers

Question - 71 : - Do ActionForms  have to be true JavaBeans?

Answer - 71 : - 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 - 72 : - Library Dependency

Answer - 72 : - 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 7.0.)

Question - 73 : - 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 - 73 : - 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

Question - 74 : - Can I use other beans or hashmaps with ActionForms?

Answer - 74 : - 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="orde

Question - 75 : - Action.execute() and Action.getResources()

Answer - 75 : - 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 - 76 : - What is ActionServlet?

Answer - 76 : - The class org.apache.struts.action.ActionServlet is the called the ActionServlet. In the the Jakarta Struts Framework this class plays the role of controller. All the requests to the server goes through the controller. Controller is responsible for handling all the requests.

Question - 77 : - What's the best way to deal with migrating a large application from Struts to JSF? Is there any tool support that can help?

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

Question - 78 : - What is Struts Validator Framework?

Answer - 78 : - Struts Framework provides the functionality to validate the form data. It can be use to validate the data on the users browser as well as on the server side. Struts Framework emits the java scripts and it can be used validate the form data on the client browser. Server side validation of form can be accomplished by sub classing your From Bean with DynaValidatorForm class. The Validator framework was developed by David Winterfeldt as third-party add-on to Struts. Now the Validator framework is a part of 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 doing any extra settings.

Question - 79 : - Do I have to have a separate ActionForm bean for every HTML form?

Answer - 79 : - This is an interesting question. As a newbie, it is a good practice to create a new ActionForm for each action sequence. You can use DynaActionForms to help reduce the effort required, or use the code generation facilities of your IDE. Some issues to keep in mind regarding reuse of form beans are as follows: * Validation - You might need to use different validation rules depending upon the action that is currently being executed. * Persistence - Be careful that a form populated in one action is not unexpectedly reused in a different action. Multiple entries in struts-config.xml for the same ActionForm subclass can help (especially if you store your form beans in session scope). Alternatively, storing form beans in request scope can avoid unexpected interactions (as well as reduce the memory footprint of your application, because no server-side objects will need to be saved in between requests. * Checkboxes - If you do as recommended and reset your boolean properties (for fields presented as checkboxes), and the page you are currently displaying does not have a checkbox for every boolean property on the form bean, the undisplayed boolean properties will always appear to have a false value. * Workflow - The most common need for form bean reuse is workflow. Out of the box, Struts has limited support for workflow, but a common pattern is to use a single form bean with all of the properties for all of the pages of a workflow. You will need a good understanding of the environment (ActionForms, Actions, etc.) prior to being able to put together a smooth workflow environment using a single form bean. As you get more comfortable, there are a few shortcuts you can take in order to reuse your ActionForm beans. Most of these shortcuts depend on how you have chosen to implement your Action / ActionForm combinations.

Question - 80 : - Are the Struts tags XHTML compliant ?

Answer - 80 : - If you use an <html:html xhtml="true> or <html:xhtml/> element on your page, the tags will render as XHTML (since Struts 1.1).

Computer Contributors

Rajeev Katiyar
Yes Baroda

Share your email for latest updates


Our partners