Professional Documents
Culture Documents
com/Interview-
Questions/Struts/Do_we_need_to_pay_the_Struts_if_being_used_in_co.html
***************************************************************************************************
*****
1. What is Struts?
1.Struts is a web page development framework and an open source software that
helps developers build web applications quickly and easily. Struts combines Java
Servlets, Java Server Pages, custom tags, and message resources into a unified
framework. It is a cooperative, synergistic platform, suitable for development
teams, independent developers, and everyone between.
2.The core of the Struts framework is a flexible control layer based on standard
technologies like Java Servlets, JavaBeans, ResourceBundles, and XML, as well as
various Jakarta Commons packages. Struts encourages application architectures
based on the Model 2 approach, a variation of the classic Model-View-Controller
(MVC) design paradigm. Struts provides its own Controller component and
integrates with other technologies to provide the Model and the View. For the
Model, Struts can interact with standard data access technologies, like JDBC and
EJB, as well as most any third-party packages, like Hibernate, iBATIS, or Object
Relational Bridge. For the View, Struts works well with JavaServer Pages, including
JSTL and JSF, as well as Velocity Templates, XSLT, and other presentation systems.
The Struts framework provides the invisible underpinnings every professional web
application needs to survive. Struts helps you create an extensible development
environment for your application, based on published standards and proven design
patterns.
*************************************************************************************
In the MVC design pattern, application flow is mediated by a central Controller. The
Controller delegates requests to an appropriate handler. The handlers are tied to a
Model, and each handler acts as an adapter between the request and the Model.
The Model represents, or encapsulates, an application's business logic or state.
Control is usually then forwarded back through the Controller to the appropriate
View. The forwarding can be determined by consulting a set of mappings, usually
loaded from a database or configuration file. This provides a loose coupling between
the View and Model, which can make an application significantly easier to create
and maintain.
Controller--Servlet controller which supplied by Struts itself; View --- what you can
see on the screen, a JSP page and presentation components; Model --- System state
and a business logic JavaBeans.
*************************************************************************************
3. Who makes the 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.
*************************************************************************************
No. Struts is available for commercial use at no charge under the Apache Software
License. You can also integrate the Struts components into your own framework just
as if they were writtern in house without any red tape, fees, or other hassles.
*************************************************************************************
*************************************************************************************
*************************************************************************************
Struts implements the MVC/Layers pattern through the use of ActionForwards and
ActionMappings to keep control-flow decisions out of presentation layer.
*************************************************************************************
ApplicationResources.properties
struts-config.xml
*************************************************************************************
10. What helpers in the form of JSP pages are provided in Struts framework?
--struts-html.tld
--struts-bean.tld
--struts-logic.tld
*************************************************************************************
• The Struts localization strategies reduce the need for redundant JSPs
• The Struts is open source and well documented (code to be examined easily)
*************************************************************************************
12. How you will enable front-end validation based on the xml in validation.xml?
The < html:javascript > tag to allow front-end validation based on the xml in
validation.xml. For example the code: < html:javascript formName=logonForm
dynamicJavascript=true staticJavascript=true / > generates the client side java
script for the form logonForm as defined in the validation.xml file. The <
html:javascript > when added in the jsp file generates the client site validation
script.
*************************************************************************************
*************************************************************************************
14. How you will make available any Message Resources Definitions file to the
Struts Framework Environment?
Message Resources Definitions file are simple .properties files and these files
contains the messages that can be used in the struts project. Message Resources
Definitions files can be added to the struts-config.xml file through < message-
resources / > tag. Example: < message-resources parameter= MessageResources /
>
***************************************************************************************************
*****
Here is the code of Action Class that returns the ActionForward object.
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.apache.struts.action.Action;
import org.apache.struts.action.ActionForm;
import org.apache.struts.action.ActionForward;
import org.apache.struts.action.ActionMapping;
ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
return mapping.findForward(\"testAction\");
***************************************************************************************************
*****
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.
The Validator Framework uses two XML configuration files validator-rules.xml and
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.
***************************************************************************************************
*****
20. How you will display validation fail errors on jsp page?
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.
***************************************************************************************************
*****
Java Servlets are designed to handle requests made by Web browsers. Java
ServerPages are designed to create dynamic Web pages that can turn billboard
sites into live applications. Struts uses a special Servlet as a switchboard to route
requests from Web browsers to the appropriate ServerPage. This makes Web
applications much easier to design, create, and maintain.
***************************************************************************************************
*****
***************************************************************************************************
*****
There are several active committers to the Struts project, working cooperatively
from around the globe. Dozens of individual developers and committers contributed
to the Struts 1.x codebase. All interested Java developers are invited to contribute
to the project. Struts is a Apache Software Foundation project, with the mission to
"provide secure, enterprise-grade server solutions based on the Java Platform that
are developed in an open and cooperative fashion".
Struts was created by Craig R. McClanahan and donated to The Apache Software
Foundation in May 2000. Craig was the primary developer of both Struts 1.x and
Tomcat 4. Tomcat 4 was the basis for the official reference implementation for a
servlet 2.3 and JSP 1.2 container.
Craig's current focus is as architect of the Sun Java Studio Creator (formerly Project
Rave). Craig also serves as the Specification Lead for JavaServer Faces (JSR-127),
and is the Web Layer Architect for the Java2 Enterprise Edition (J2EE) platform as a
whole.
***************************************************************************************************
*****
It's a reference to struts in the architectural sense, a reminder of the nearly invisible
pieces that hold up buildings, houses, and bridges.
***************************************************************************************************
*****
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.
***************************************************************************************************
*****
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.
***************************************************************************************************
*****
Since the full source code for Struts is available, we also provide complete
instructions for compiling your own Struts JAR from scratch. (This is actually easier
than it looks!)
Your Struts application can usually be deployed using a standard WAR file. In most
cases, you simply deposit the WAR file on your application server, and it is installed
automatically. If not, step-by-step installation instructions for various servlet
containers are available.
***************************************************************************************************
*****
When you are compiling an application that uses the Struts classes, you must have
the "struts.jar" on the classpath your compiler sees -- it does not have to be on your
CLASSPATH environment variable.
Why is that an important distinction? Because if you are using a servlet container on
your development machine to test your application, the "struts.jar" must not be on
your CLASSPATH environment variable when running the container. (This is because
each Web application must also have their own copy of the Struts classes, and the
container will become confused if it is on the environment path as well.)
* Use ANT for building your projects -- it can easily assemble classpaths for the
compiler. (This is how Struts itself is built, along with Tomcat and most other Java-
based projects).
* Use an IDE where you can configure the "class path" used for compilation
independent of the CLASSPATH environment variable.
* Use a shell script that temporarily adds struts.jar to the classpath just for
compilation, for example javac -classpath /path/to/struts.jar:$CLASSPATH $@
***************************************************************************************************
*****
Struts currently has two testing environments, to reflect the fact that some things
can be tested statically, and some really need to be done in the environment of a
running servlet container.
For static unit tests, we use the JUnit framework. The sources for these tests are in
the "src/test" hierarchy in the source repository, and are executed via the
"test.junit" target in the top-level build.xml file. Such tests are focused on the low-
level functionality of individual methods, are particularly suitable for the static
methods in the org.apache.struts.util utility classes. In the test hierarchy, there are
also some "mock object" classes (in the org.apache.struts.mock package) so that
you can package up things that look like servlet API and Struts API objects to pass in
as arguments to such tests.
Another valuable tool is Struts TestCase which provides a useful harness for Action
classes that can be used with JUnit or Cactus.
***************************************************************************************************
*****
30. If the framework doesn't do what I want, can I request that a feature be added?
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.)
***************************************************************************************************
*****
The Struts package comes complete with a Users Guide to introduce people to the
framework and its underlying technologies. Various components also have their own
in-depth Developers Guide, to cover more advanced topics. Comprehensive
Javadocs are included along with the full source code. For your convenience, these
are bundled together as a self-installing application. The struts-documentation.war
is the same bundle that is deployed as the Struts Web site.
The Strut's mailing list is also very active, and welcomes posts from new users.
Before posting a new question, be sure to consult the MAILING LIST ARCHIVE and
the very excellent How To Ask Questions The Smart Way by Eric Raymond. Please
do be sure to turn off HTML in your email client before posting.
***************************************************************************************************
*****
32. What's the difference between Struts and Turbine? What's the difference
between Struts and Expresso?
If you are starting from scratch, packages like Turbine and Expresso can be very
helpful since they try to provide all of the basic services that your team is likely to
need. Such services include things like data persistence and logging.
If you are not starting from scratch, and need to hook up your web application to an
existing infrastructure, then "plain vanilla" Struts can be a better choice. The core
Struts framework does not presuppose that you are using a given set of data
persistence, presentation, or logging tools. Anything goes =:0)
See also
***************************************************************************************************
*****
33. Why aren't the Struts tags maintained as part of the Jakarta Taglibs project?
Development of both products began about the same time. Leading up to the
release of 1.0, it was thought better to continue to develop the taglibs alongside the
controller. Now that 1.0 is out, the JavaServer Pages Standard Taglib is in active
development. Once work on JSTL stabilizes, the Struts taglibs will be revisited. Tags
which are not linked directly to the framework may be hosted at Jakarta Taglibs
instead.
***************************************************************************************************
*****
***************************************************************************************************
*****
35. 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.
***************************************************************************************************
*****
The inventor of Struts, Craig McClanahan, is the specification co-lead for JavaServer
Faces (JSR 127), and architect of the reference implemenation as well as Java Studio
Creator. Both JSTL and JSF are complementary to Struts.
The mainstay of the Struts framework is the controller components, which can be
used with any Java presentation technology. As new technologies become available,
it is certain that new "glue" components will also appear to help these technologies
work as well with Struts.
Struts originally came bundled with a set of custom JSP tags. Today, several
extensions are available to help you use Struts with other popular presentation
technologies, like XSLT and Velocity. Likewise, extensions for JSTL and JSF are now
available as well.
The JSTL reference implementation is available through the Jakarta Taglibs site. A
JSTL taglibs for Struts, Struts-El , is available and distributed with Struts beginning
with the 1.1 release.
The JSF specification and reference implementation is available through Sun's The
JSF specification and reference implementation is available through Sun's Java
ServerFaces page. An early-release JavaServer Faces taglib for Struts, Struts-Faces,
is also in early release and available through the nightly build. The Struts Faces
taglib is expected to work with any compliant JSF implementation, including
MyFaces.
***************************************************************************************************
*****
Struts should work well with any development environment that you would like to
use, as well as with any programmers editor. The members of the Struts
development team each use their own tools such as Emacs, IDEA, Eclipse, and
NetBeans.
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.
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.
***************************************************************************************************
*****
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.
* 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.
***************************************************************************************************
*****
40. 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.
***************************************************************************************************
*****
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.
Since the goal of struts is to enforce this separation, it just makes more sense for
Struts to own the ActionForm.
***************************************************************************************************
*****
The utilities that Struts uses (Commons-BeanUtils since 1.1) require that ActionForm
properties follow the JavaBean patterns for mutators and accessors (get*,set*,is*).
Since Struts uses the Introspection API with the ActionForms, some containers may
require that all the JavaBean patterns be followed, including declaring "implements
Serializable" for each subclass. The safest thing is to review the JavaBean
specification and follow all the prescribed patterns.
Since Struts 1.1, you can also use DynaActionForms and mapped-backed forms,
which are not true JavaBeans. For more see ActionForm classes in the User Guide
and Using Hashmaps with ActionForms in this FAQ.
***************************************************************************************************
*****
43. Can I use multiple HTML form elements with the same name?
Yes. Define the element as an array and Struts will autopopulate it like any other.
***************************************************************************************************
*****
44. Can I use multiple HTML form elements with the same name?
Yes. The issue is that only one action class can be associated with a single form. So
the real issue is how do I decode multiple submit types to a single Action class.
There is more than one way to achieve this functionality.
The way that is suggested by struts is right out of the javadoc for
LookupDispatchAction . Basically, LookupDispatchAction is using the keys from
ApplicationProperties.resources as keys to a map of actions available to your Action
class. It uses reflection to decode the request and invoke the proper action. It also
takes advantage of the struts <html:submit> tags and is straight forward to
implement.
You can roll your own with JavaScript events and javascript:void
(document.forms["myform"].submit) on any html element. This gives you control of
how you want your page to look. Again you will have to decode the expected action
in the execute method of your action form if you choose this route.
***************************************************************************************************
*****
45. Why doesn't the focus feature on the <html:form> tag work in every
circumstance?
***************************************************************************************************
*****
A problem with a checkbox is that the browser will only include it in the request
when it is checked. If it is not checked, the HTML specification suggests that it not
be sent (i.e. omitted from the request). If the value of the checkbox is being
persisted, either in a session bean or in the model, a checked box can never
unchecked by a HTML form -- because the form can never send a signal to uncheck
the box. The application must somehow ascertain that since the element was not
sent that the corresponding value is unchecked.
The recommended approach for Struts applications is to use the reset method in
the ActionForm to set all properties represented by checkboxes to null or false. The
checked boxes submitted by the form will then set those properties to true. The
omitted properties will remain false. Another solution is to use radio buttons
instead, which always submit a value.
It is important to note that the HTML specification recommends this same behavior
whenever a control is not "successful". Any blank element in a HTML form is not
guaranteed to submitted. It is therefor very important to set the default values for
an ActionForm correctly, and to implement the reset method when the ActionForm
might kept in session scope.
***************************************************************************************************
*****
You can submit a form with a link as below. BTW, the examples below assume you
are in an block and 'myForm' is picked up from the struts-config.xml name field of
the action.
Now the trick in the action is to decode what action you intend to perform. Since
you are using JavaScript, you could set a field value and look for it in the request or
in the form.
onclick='document.forms["myForm"].myAction.value="save";
document.forms["myForm"].submit();' />
onclick='document.forms["myForm"].myAction.value="delete";
document.forms["myForm"].submit();' />
if (myAction.equals("save") {
} else if (myAction.equals("delete") {
// ... delete action ...
This is just one of many ways to achieve submitting a form and decoding the
intended action. Once you get used to the framework you will find other ways that
make more sense for your coding style and requirements. Just remember this
example is completely non-functional without JavaScript.
Here is a link which utilizes the LookupDispatch action to submit forms with multiple
actions without javascript: http://husted.com/struts/tips/003.html
***************************************************************************************************
*****
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.
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.
***************************************************************************************************
*****
49. Can't I just create some of my JavaBeans in the JSP using a scriptlet?
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.
***************************************************************************************************
*****
Yes. There are several ways that you can use other beans or hashmaps with
ActionForms.
* 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:
<html:select property="colorSelected">
</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:
request.setAttribute("searchResults",results);
Then the view can iterate through the results using the "searchResults" request key
to reference the DTO:
<td>..other properties...</td></tr>
</logic:iterate>
***************************************************************************************************
*****
The Struts tags seem to provide only the most rudimentary functionality. Why is
there not better support for date formatting and advanced string handling?
Three reasons:
First, work started on the JSTL and we didn't want to duplicate the effort.
Second, work started on Java Server Faces, and we didn't want to duplicate that
effort either.
Since the Struts tags are open source, you can extend them to provide whatever
additional formatting you may need. If you are interested in a pre-written taglib that
offers more layout options, see the struts-layout taglib.
In the same arena, there is a well regarded contributor taglib that can help you
create Menus for your Struts applications.
***************************************************************************************************
*****
52. 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.
***************************************************************************************************
*****
53. 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/
***************************************************************************************************
*****
54. Why does the option tag render selected=selected instead of just selected?
***************************************************************************************************
*****
The short answer to this question is: No, you are not limited to JavaServer Pages.
The longer answer is that you can use any type of presentation technology which
can be returned by a web server or Java container. The list includes but is not
limited to:
* JavaServer Pages,
* HTML pages,
* WML files,
* Java servlets,
* XML/XLST
Some people even mix and match apparently unrelated technologies, like PHP, into
the same web application.
***************************************************************************************************
*****
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:
return (this.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.
* 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 referring to the same property. Instead, the language
will think you have a read-only property named "foo" and a write-only property
named "bar".
* Using more than one setter method with the same name - The Java language lets
you "overload" methods, as long as the argument types are different. For example,
you could have a setStartDate(java.util.Date date) method and a
setStartDate(String date) method in the same class, and the compiled code would
know which method to call based on the parameter type being passed. However,
doing this for form bean properties will prevent Java from recognizing that you have
a "startDate" property at all.
There are other rules to follow if you want other features of your form beans to be
exposed. These include indexed attributes and mapped attributes. They are
covered in detail in other areas of the Struts documentation, in particular:
indexedprops.html
For a complete explanation of what a JavaBean is, and everything it can do, see the
JavaBeans Specification (version 1.01) at:
http://java.sun.com/products/javabeans/docs/beans.101.pdf
***************************************************************************************************
*****
57. Do I have to have a separate ActionForm bean for every HTML form?
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.
* 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.
The simplest way to prepopulate a form is to have an Action whose sole purpose is
to populate an ActionForm and forward to the servlet or JSP to render that form
back to the client. A separate Action would then be use to process the submitted
form fields, by declaring an instance of the same form bean name.
The struts-example example application that is shipped with Struts illustrates this
design pattern nicely. Note the following definitions from the struts-config.xml file:
...
<form-beans>
...
<form-bean name="registrationForm"
type="org.apache.struts.webapp.example.RegistrationForm"/>
...
</form-beans>
...
<action-mappings>
...
<action path="/editRegistration"
type="org.apache.struts.webapp.example.EditRegistrationAction"
name="registrationForm"
scope="request"
validate="false"/>
...
<action path="/saveRegistration"
type="org.apache.struts.webapp.example.SaveRegistrationAction"
name="registrationForm"
input="registration"
scope="request"/>
...
</action-mappings>
* Both the /editRegistration and /saveRegistration actions use the same form bean.
* When the /editRegistration action is entered, Struts will have pre-created an
empty form bean instance, and passed it to the execute() method. The setup action
is free to preconfigure the values that will be displayed when the form is rendered,
simply by setting the corresponding form bean properties.
* When the setup action completes configuring the properties of the form bean, it
should return an ActionForm that points at the page which will display this form. If
you are using the Struts JSP tag library, the action attribute on your <html:form>
tag will be set to /saveRegistration in order for the form to be submitted to the
processing action.
* Note that the setup action (/editRegistration) turns off validation on the form that
is being set up. You will normally want to include this attribute in the configuration
of your setup actions, because you are not planning to actually process the results
-- you simply want to take advantage of the fact that Struts will precreate a form
bean instance of the correct class for you.
* The processing action (/saveRegistration), on the other hand, leaves out the
validate attribute, which defaults to true. This tells Struts to perform the validations
associated with this form bean before invoking the processing action at all. If any
validation errors have occurred, Struts will forward back to your input page
(technically, it forwards back to an ActionForward named "registration" in this case,
because the example webapp uses the inputForward attribute in the element -- see
the documentation describing struts-config.xml for more information) instead of
calling your processing action.
***************************************************************************************************
*****
Yes. If your Action does not need any data and it does
<action path="/logoff"
type="org.apache.struts.webapp.example.LogoffAction">
</action>
This action needs no data other than the user's session, which
it can get from the Request, and it doesn't need to prepare any
***************************************************************************************************
*****
59. Can you give me a simple example of using the requiredif Validator rule?
<form name="medicalStatusForm">
<field
property="pregnancyTest" depends="validwhen">
<arg0 key="medicalStatusForm.pregnancyTest.label"/>
<var>
<var-name>test</var-name>
</var>
</field>
<form name="medicalStatusForm">
<field
property="pregnancyTest" depends="requiredif">
<arg0 key="medicalStatusForm.pregnancyTest.label"/>
<var>
<var-name>field[0]</var-name>
<var-value>sex</var-value>
</var>
<var>
<var-name>fieldTest[0]</var-name>
<var-value>EQUAL</var-value>
</var>
<var>
<var-name>fieldValue[0]</var-name>
<var-value>F</var-value>
</var>
<var>
<var-name>field[1]</var-name>
<var-value>sex</var-value>
</var>
<var>
<var-name>fieldTest[1]</var-name>
<var-value>EQUAL</var-value>
</var>
<var>
<var-name>fieldValue[1]</var-name>
<var-value>f</var-value>
</var>
<var>
<var-name>fieldJoin</var-name>
<var-value>OR</var-value>
</var>
</field>
<field
property="testResult" depends="requiredif">
<arg0 key="medicalStatusForm.testResult.label"/>
<var>
<var-name>field[0]</var-name>
<var-value>pregnancyTest</var-value>
</var>
<var>
<var-name>fieldTest[0]</var-name>
<var-value>NOTNULL</var-value>
</var>
</field>
</form>
***************************************************************************************************
*****
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...
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.
***************************************************************************************************
*****
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.
type="org.apache.struts.webapp.example.EditRegistrationAction"
attribute="registrationForm"
scope="request"
validate="false">
</action>
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) -->
<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) -->
<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>
/* com/AAction.java */
...
public ActionForward
execute(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
Exception
// Do something
return mapping.findForward("success");
/* com/BAction.java */
...
public ActionForward
execute(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
Exception
// Do something else
return mapping.findForward("success");
...
<action-mappings type=
"org.apache.struts.action.ActionMapping">
<action path="/A"
type="com.AAction"
validate="false">
</action>
<action path="/B"
type="com.BAction"
scope="session"
validate="false">
</action>
</action-mappings>
...
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.
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.
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.
Answer 2
int i=1;
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
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);
Connect cn = ng.getConnection();
it's work.
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.
66. What's the best way to deal with migrating a large application from Struts to
JSF? Is there any tool support that can help?
If you have developed web applications long enough, you will realize a recurring
pattern emerges: when the backend (e.g. the EJB tier) throws you an exception, you
nearly always need to display an error page corresponding to the type of that
exception. Sooner or later, you will come up with a mechanism to use a lookup table
(e.g. an HashMap) to lookup an error page from the exception class.
Struts 1.1 now provides a similar but more powerful mechanism to declare
exception handling. In Struts 1.1, you can declare in the struts-config.xml the
associations between an exception class and an exception handler. Using the
default exception handler included in Struts, you can also specify the path of the
error pages. With this information, Struts will automatically forward to the specified
pages when an uncaught exception is thrown from an Action.
Like other facilities in Struts, the exception handlers are pluggable. You can write
and define your own handler classes if needed.
68. Can you compare the advantages and disadvantages of JSF vs. Struts ?
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 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.
* 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.
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 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.
69. Both JSF and Struts will continue to exist for a while ?
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.
http://some-host.com/myApp/module2/editSubscription.do
/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".
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.
72. Validator
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.
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.
75. ActionServlet Configurations
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.
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.)
According to the Servlet specification, resources (e.g. JSP files) stored under WEB-
INF are protected and cannot be accessed directly by the browsers. One design
idiom for Struts 1.0 is to put all the JSP files under WEB-INF and front them by
Actions so that clients cannot illegally access the JSPs.
In the Jakarta Struts Framework this class plays the role of controller.
81. How can one make any “Message Resources” definitions file available to the
“Struts Framework” environment?
Answer: “Message Resources” definitions file are simple .properties files and
these files contain the messages that can be used in the struts project.
The “Action Class” is part of the “Model” and is a wrapper around 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 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.
Here is the code of Action Class that returns the ActionForward object.
package j2eeonline.jdj.com;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.apache.struts.action.Action;
import org.apache.struts.action.ActionForm;
import org.apache.struts.action.ActionForward;
import org.apache.struts.action.ActionMapping;
return mapping.findForward("testAction");
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.
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.
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
86. Describe the details of XML files used in the “Validator Framework”?
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.
87. How would you display “validation fail” errors on a JSP page?
88. How can one enable front-end validation based on the xml in validation.xml?
generates the client side JavaScript for the form "logonForm" as defined in the
validation.xml file.
The <html:javascript> when added in the JSP file generates the client side
validation script.