husted 2002/10/29 03:09:24
Added: doc/faqs ssl.xml project.xml newbie.xml kickstart.xml
index.xml helping.xml
Log:
+ Setup FAQ and Howto section.
Revision Changes Path
1.1 jakarta-struts/doc/faqs/ssl.xml
Index: ssl.xml
===================================================================
<?xml version="1.0"?>
<document url="./ssl.xml">
<properties>
<author>Steve Ditlinger</author>
<title>Secure Socket Layer and Web Applications</title>
</properties>
<body>
<chapter href="ssl" name="Secure Socket Layer and Web Applications">
<section href="overview" name="Overview">
<p>
Many web applications, especially those deployed for e-commerce, necessitate the
transmission of sensitive data between the web server and the client browser. This
data
may include passwords, credit card numbers, bank account numbers or any other
information that users would not want to divulge to the general public. To protect
sensitive data during transmission, application developers typically use the Secure
Sockets Layer (SSL) and its companion protocol, HTTP over Secure Sockets Layer
(HTTPS). HTTPS employs SSL to protect data by encrypting it at the source, be it the
server or the client, and decrypting it at the destination. This prevents anyone
monitoring
Internet data transmissions from easily capturing this data. The client and server
exchange public keys to enable encryption and decryption to occur.
</p>
<p>
The encryption/decryption process comes at a performance price, however. The
throughput of data for a web server transmitting via HTTPS is often as little as
one-tenth
that of data transmission via HTTP. For this reason, it is undesirable to deploy an
entire
web application under SSL. For fastest performance, it is best to deploy a web
application under HTTP and employ HTTPS only for those pages and processes that
transmit sensitive data.
</p>
</section>
<section href="mixing" name="Mixing Protocols in Web Applications">
<p>
Switching back and forth between the two protocols can require hard-coding the
protocol
and full URL in every link to each resource in the web application. This creates an
ongoing maintenance headache for developers each time a server name changes or secure
protocol requirements change for resources in the web app.
</p>
<p>
Another significant hazard is that there is nothing to prevent a user from
specifying the
wrong protocol by manually entering a URL into the browser. The penalty for manually
specifying HTTPS for a page or servlet that does not require HTTPS is reduced
performance. Far worse is the penalty for manually specifying HTTP for non-secure
access of a page that does require HTTPS: public exposure of sensitive data.
</p>
</section>
<section href="help" name="Help from Deployment Descriptor">
<p>
To help overcome the problem of non-secure access of sensitive data, the Java Servlet
Specification (versions 2.2 and 2.3) defines the transport-guarantee element of the
web.xml deployment descriptor file. The transport-guarantee element must specify one
of three types of protection for communication between client and server: NONE,
INTEGRAL, or CONFIDENTIAL. For most containers a specification of INTEGRAL
or CONFIDENTIAL is treated as a requirement for SSL usage. Web application
containers will prevent users from accessing web resources over HTTP if they have
been
so specified.
</p>
<p>
The implementation for blocking HTTP access to web resources specified as INTEGRAL
or CONFIDENTIAL varies from container to container. If a user attempts to access such
a resource over HTTP, some containers will present that user with an error message
instructing them to use the HTTPS protocol for accessing the requested resource.
Other
containers will actually redirect the request using the HTTPS protocol, but then
continue
using the HTTPS protocol for all subsequent requests, even those for resources with a
transport-guarantee specification of NONE.
</p>
</section>
<section href="sslext" name="The sslext Struts Extension">
<p>
An extension to Struts 1.1, named sslext, helps solve many of these issues for Struts
developers. It extends the ActionConfig class, RequestProcessor, and Plugin classes
to
define a framework where developers may specify the transmission protocol behavior
for
Struts applications. Within the Struts configuration file, developers specify which
action
requests require HTTPS transmission and which should use HTTP. Developers can also
specify whether to redirect "improperly-protocoled" requests to the correct protocol.
</p>
<p>
In addition to these extensions, the <html:link> and the <html:form> tags have
been
extended. In these extensions, the Struts actions specified in either of these tags
are
analyzed to determine the protocol that should be used in requesting that action. The
HTML generated by these tags will specify the proper protocol. An additional custom
tag is defined for allowing users to specify the transmission protocol for an
individual
JSP. This is most often used for form-based authentication pages.
</p>
</section>
<section href="legacy" name="Legacy Browser Issue">
<p>
One additional complication faced by developers of web applications is that some
browsers (e.g. pre-6.0 versions of Netscape Navigator) will treat requests to
different
protocols and ports on the same server as requests to different domains. This causes
these browsers to initiate a new session each time a different protocol or port is
specified
in a request. This problem can only be solved at the container level. Some containers
have a "session domain" or "cookie domain" configuration parameter to allow the
session
to be shared across different servers in the same domain. As an example, the Weblogic
Server has a "CookieDomain" property configured in its weblogic.xml deployment
descriptor. Thankfully, the effects of this problem are diminishing as people upgrade
their browsers to the current versions.
</p>
</section>
<section href="containers" name="Configuring Containers for SSL">
The procedure for configuring SSL for a container will be specific to that
container. The
procedure for enabling SSL for Tomcat can be found
<a href="http://jakarta.apache.org/tomcat/tomcat-4.1-doc/ssl-howto.html";>here</a>.
</section>
</chapter></body></document>
1.1 jakarta-struts/doc/faqs/project.xml
Index: project.xml
===================================================================
<?xml version="1.0" encoding="ISO-8859-1"?>
<project name="Struts Framework"
href="http://jakarta.apache.org/struts";
image="images/struts.gif">
<title>Struts Framework</title>
<menu name="FAQs">
<item href="kickstart.html" name="Kickstart"/>
<item href="newbie.html" name="Newbie"/>
<item href="helping.html" name="How to Help"/>
</menu>
<menu name="Howtos">
<item href="ssl.html" name="SSL"/>
</menu>
<menu name="Welcome">
<item name="Home" href="../index.html"/>
<item name="News & Status" href="../news.html"/>
<item name="FAQs and Howtos" href="../faqs/index.html"/>
<item name="Resources" href="../resources/index.html"/>
<item name="List Archive"
href="http://nagoya.apache.org/eyebrowse/SummarizeList?listId=42"/>
<item name="Who We Are" href="../volunteers.html"/>
</menu>
</project>
1.1 jakarta-struts/doc/faqs/newbie.xml
Index: newbie.xml
===================================================================
<?xml version="1.0"?>
<document url="./kickstart.xml">
<properties>
<author>Ted Husted</author>
<author>James Holmes</author>
<title>The Struts User's Guide - Newbie FAQ</title>
</properties>
<body>
<chapter href="faq" name="Newbie FAQ">
<section href="contents" name="Index">
<p>
Here are answers to 24 common questions people ask when using Struts on their first
project. <b>For an in-depth, searchable FAQ, visit our friends at <a
href="http://www.jguru.com/faq/home.jsp?topic=Struts";>JGuru</a>.</b>
</p>
<p><font color="red"><b>UNDER CONSTRUCTION</b></font> (contributions welcome)</p>
<ul>
<li><a href="#reload">Why was reload removed from Struts 1.1?</a></li>
<li><a href="#modules">What is a modular application? What does module-relative
mean?</a></li>
<li><a href="#naming">Why are some of the class and element names
counter-intuitive?</a></li>
<li>Why is ActionForm a base class rather than an interface?</li>
<li>Do I have to have a separate ActionForm bean for every HTML form?</li>
<li>do ActionForms have to be true JavaBeans?</li>
<li>Can I use other beans or hashmaps with ActionForms?</li>
<li>How can I prepopulate a form?</li>
<li><a href="#multiple">Can I use multiple HTML form elements with the same
name?</a></li>
<li><a href="#actionforms">Why are my checkboxes not being set from ON to
OFF?</a></li>
<li>How can I capture binary or formatted values, like dates or telephone
numbers?</li>
<li>Why do my option lists disappear when validation fails?</li>
<li><a href="#scriptlets">Can't I just create some of my JavaBeans in the JSP
using a scriptlet?</a></li>
<li><a href="#tags">Why do the Struts tags provide for so little
formatting?</a></li>
<li>When is the best time to validate input?</li>
<li>How can I avoid validating a form before data is entered?</li>
<li>How can I create a "wizard" workflow?</li>
<li>How can I "chain" Actions?</li>
<li>Can I have an Action without a form?</li>
<li>How do I access my database?</li>
<li>How can I authenticate my users?</li>
<li>How can I scroll through list of pages like the search results in
google?</li>
<li>Can I have multiple submit buttons on the same form?</li>
<li>Why can't my Javascript submit a form?</li>
<li><a href="minimization">Why does the option tag render selected="selected"
instead of just "selected"?</a></li>
<li>Can I create dynamic ActionForwards?</li>
<li>How can I use my own (ActionForm, ActionForward, ActionMapping,
ActionServlet) class?</li>
<li>Do I have to use JSPs with my application?</li>
</ul>
</section>
<section href="reload" name="Why was reload removed from Struts 1.1?">
<p>ReloadAction is not supported in 1.1 for two reasons:</p>
<ul>
<li>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.</li>
<li>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 apps can run a little faster.</li>
</ul>
</section>
<section href="modules" name="What is a modular application? What does
module-relative mean?">
<p>
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
<a href="userGuide/building_controller.html#module_config">Building Controller
Components</a> in the
User Guide.
</p>
<p>
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 application-module
level, rather than at
the application-context level, or the absolute-URL level.
</p>
<ul>
<li>Absolute URL: http://localhost/myApplication/myModule/myAction.do</li>
<li>context-relative: /myModule/myAction.do</li>
<li>module-relative: /myAction.do</li>
</ul>
</section>
<section href="naming" name="Why are some of the class and element names
counter-intuitive?">
<p>
The framework grew in the telling and as it evolved some of the names
drifted.
</p>
<p>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 classnames get locked down early and
then become difficult to change.
</p>
</section>
<section href="actionforms" name="Wither ActionForms?">
<p>
<a
href="http://www.mail-archive.com/struts-user@;jakarta.apache.org/msg19281.html">http://www.mail-archive.com/struts-user@;jakarta.apache.org/msg19281.html</a><br/>
<a
href="http://www.mail-archive.com/struts-user@;jakarta.apache.org/msg19338.html">http://www.mail-archive.com/struts-user@;jakarta.apache.org/msg19338.html</a><br/>
<a
href="http://www.mail-archive.com/struts-user@;jakarta.apache.org/msg20833.html">http://www.mail-archive.com/struts-user@;jakarta.apache.org/msg20833.html</a><br/>
</p>
</section>
<section href="JavaBeans" name="Do ActionForms have to be true JavaBeans?">
<p>
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 "<code>implements serializable</code>" for each subclass. The safest thing
is to review the
<a href="userGuide/preface.html#javabeans">JavaBean specification</a> and follow all
the prescribed patterns.</p>
</section>
<section href="multiple" name="Can I use multiple HTML form elements with the same
name?">
<p>
Yes. Define the element as an array and Struts will autopopulate it like any other.
</p>
<pre>
<code>
private String[] id= {};
public String[] getId() { return this.id; }
public void setItem(String id[]) {this.id = id;}
</code>
</pre>
<p>
And so forth
</p>
</section>
<section href="checkbox" name="Why are my checkboxes not being set from ON to OFF?">
<p>
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.
</p>
<p>
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.
</p>
<p>
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.
</p>
</section>
<section href="scriptlets" name="Can't I just create some of my JavaBeans in the JSP
using a scriptlet?">
<p>
Struts is designed to encourage a
<a href="http://www.javaworld.com/javaworld/jw-12-1999/f_jw-12-ssj-jspmvc.html";>
Model 2/MVC architecture</a>. But there is nothing that prevents you from using
Model 1
techniques in your JavaServer Pages, so the answer to the question is "Yes, you
can".
</p>
<p>
Though, using Model 1 techniques in a Struts application does go against the grain.
The approach recommended by most Struts developers is to create and populate whatever
objects the view may need in the Action, and then forward these through the request.
Some objects may also be created and stored in the session or application context,
depending on how they are used.
</p>
<p>
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.
</p>
<p>
For help with Model 1 techniques and scriptlets, you might consider joining the
<a href="http://archives.java.sun.com/jsp-interest.html";>Javasoft JSP-interest
mailing list</a>, where there are more people still using these approaches.
</p>
</section>
<section href="tags" name="Why do the Struts tags provide for so little formatting?">
<p>
<i>The Struts tags seem to provide only the most rudimentary funcationality. Why is
there not better support for date formatting and advanced string handling?</i>
</p>
<p>
Three reasons:
</p>
<p>
First, work started on the JSTL and we didn't want to duplicate the effort.
</p>
<p>
Second, work started on Java Server Faces, and we didn't want to duplicate that
effort either.
</p>
<p>
Third, in a Model 2 application, most of the formatting can be handled in the
ActionForms (or in the business tier),
so all the tag has to do is spit out a string. This leads to better reuse since the
same "how to format" code
does not need to be repeated in every instance. You can "say it once" in a JavaBean
and be done with it.
</p>
</section>
<section name="How do I access my database?">
<p>
The best thing is use the Action as a thin adaptor between the web/presentation-tier
and your business classes
(including those that access a database).
</p>
<p>
So you first design a business API that uses plain Java classes. The best thing is
to use objects that take
ordinary Java types and return a JavaBean or collection of JavaBeans. The Action
then calls these objects and
passes the result back to the web/presentation tier.
</p>
<p>
A common approach is to create an Action class for each of the business API
methods/classes that you need to call.
Ideally, all the database access code should be encapsulated in the business API
classes, so Struts doesn't know
what persistent layer you are using (or even if there is a persisentance layer). It
just passes a key or search
String and gets back a bean or collection of beans. This lets you use the same
business API classes in other
environments, and also to run unit tests against your business API outside of Struts
or a HTTP environment.
</p>
<p>
To get started, it's simplest to setup a 1:1 correspondence between the Actions and
the entry-points to
your business API. As you gain experience, you will find ways to combine your
Actions, say by using the
DispatchAction. It's even possible to use a single "framework" Action to call all of
your business
classes, as is done with Scaffold ProcessAction in the contrib folder. Using fewer
Actions does require
a deeper understanding of how Struts and MVC frameworks operate. Don't hestitate to
err on the side
of creating more Actions at first. The Struts configuration makes it easy to
refactor your Actions
later, since you can change the Action type without changing anything else in the
application.
</p>
<p>
For more, see
</p>
<p>
<a
href="http://www.mail-archive.com/struts-user@;jakarta.apache.org/msg24621.html">http://www.mail-archive.com/struts-user@;jakarta.apache.org/msg24621.html</a><br/>
<a
href="http://www.mail-archive.com/struts-user@;jakarta.apache.org/msg24709.html">http://www.mail-archive.com/struts-user@;jakarta.apache.org/msg24709.html</a><br/>
<a
href="http://www.mail-archive.com/struts-user@;jakarta.apache.org/msg24626.html">http://www.mail-archive.com/struts-user@;jakarta.apache.org/msg24626.html</a><br/>
<a
href="http://www.mail-archive.com/struts-user@;jakarta.apache.org/msg24331.html">http://www.mail-archive.com/struts-user@;jakarta.apache.org/msg24331.html</a><br/>
<a
href="http://www.mail-archive.com/struts-user@;jakarta.apache.org/msg24102.html">http://www.mail-archive.com/struts-user@;jakarta.apache.org/msg24102.html</a><br/>
<a
href="http://www.mail-archive.com/struts-user@;jakarta.apache.org/msg23501.html">http://www.mail-archive.com/struts-user@;jakarta.apache.org/msg23501.html</a><br/>
<a
href="http://www.mail-archive.com/struts-user@;jakarta.apache.org/msg23455.html">http://www.mail-archive.com/struts-user@;jakarta.apache.org/msg23455.html</a><br/>
<a
href="http://www.mail-archive.com/struts-user@;jakarta.apache.org/msg23375.html">http://www.mail-archive.com/struts-user@;jakarta.apache.org/msg23375.html</a><br/>
<a
href="http://www.mail-archive.com/struts-user@;jakarta.apache.org/msg23321.html">http://www.mail-archive.com/struts-user@;jakarta.apache.org/msg23321.html</a><br/>
<a
href="http://www.mail-archive.com/struts-user@;jakarta.apache.org/msg23098.html">http://www.mail-archive.com/struts-user@;jakarta.apache.org/msg23098.html</a><br/>
<a
href="http://www.mail-archive.com/struts-user@;jakarta.apache.org/msg22713.html">http://www.mail-archive.com/struts-user@;jakarta.apache.org/msg22713.html</a><br/>
<a
href="http://www.mail-archive.com/struts-user@;jakarta.apache.org/msg21974.html">http://www.mail-archive.com/struts-user@;jakarta.apache.org/msg21974.html</a><br/>
<a
href="http://www.mail-archive.com/struts-user@;jakarta.apache.org/msg21026.html">http://www.mail-archive.com/struts-user@;jakarta.apache.org/msg21026.html</a><br/>
<a
href="http://www.mail-archive.com/struts-user@;jakarta.apache.org/msg19338.html">http://www.mail-archive.com/struts-user@;jakarta.apache.org/msg19338.html</a><br/>
<a
href="http://www.mail-archive.com/struts-user@;jakarta.apache.org/msg18323.html">http://www.mail-archive.com/struts-user@;jakarta.apache.org/msg18323.html</a><br/>
<a
href="http://www.mail-archive.com/struts-user@;jakarta.apache.org/msg14975.html">http://www.mail-archive.com/struts-user@;jakarta.apache.org/msg14975.html</a><br/>
<a
href="http://www.mail-archive.com/struts-user@;jakarta.apache.org/msg14914.html">http://www.mail-archive.com/struts-user@;jakarta.apache.org/msg14914.html</a><br/>
<a
href="http://www.mail-archive.com/struts-user@;jakarta.apache.org/msg14435.html">http://www.mail-archive.com/struts-user@;jakarta.apache.org/msg14435.html</a><br/>
<a
href="http://www.mail-archive.com/struts-user@;jakarta.apache.org/msg01562.html">http://www.mail-archive.com/struts-user@;jakarta.apache.org/msg01562.html</a>
</p>
<p>
Transformation/Data Transfer<br/>
<a
href="http://www.mail-archive.com/struts-user@;jakarta.apache.org/msg24480.html">http://www.mail-archive.com/struts-user@;jakarta.apache.org/msg24480.html</a><br/>
<a
href="http://www.mail-archive.com/struts-user@;jakarta.apache.org/msg23623.html">http://www.mail-archive.com/struts-user@;jakarta.apache.org/msg23623.html</a><br/>
<a
href="http://www.mail-archive.com/struts-user@;jakarta.apache.org/msg10195.html">http://www.mail-archive.com/struts-user@;jakarta.apache.org/msg10195.html</a><br/>
<a
href="http://www.mail-archive.com/struts-user@;jakarta.apache.org/msg10205.html">http://www.mail-archive.com/struts-user@;jakarta.apache.org/msg10205.html</a>
</p>
</section>
<section name="How can I authenticate my users?">
<p>
<a
href="http://www.mail-archive.com/struts-user@;jakarta.apache.org/msg24504.html">http://www.mail-archive.com/struts-user@;jakarta.apache.org/msg24504.html</a><br/>
<a
href="http://www.mail-archive.com/struts-user@;jakarta.apache.org/msg22949.html">http://www.mail-archive.com/struts-user@;jakarta.apache.org/msg22949.html</a>
</p>
</section>
<section href="pager" name="How can I scroll through list of pages like the search
results in google?">
<p>Many Struts developers use the Pager from the JSPTags site.</p>
<p><a
href="http://jsptags.com/tags/navigation/pager/";>http://jsptags.com/tags/navigation/pager/</a></p>
</section>
<section href="minimization" name="Why does the option tag render selected=selected
instead of just selected?">
<p>
Attribute minimization (that is, specifying an attribute with no value) is
a place where HTML violates standard XML syntax rules. This matters a lot
for people writing to browsers that support XHTML, where doing so makes
the page invalid.It's much better for Struts to use the expanded syntax,
which works the same on existing browsers interpreting HTML, and newer
browsers that expect XHTML-compliant syntax. Struts is following the
behavior recommended by the <a href="http://www.w3.org/TR/xhtml1/#h-4.5";>
XHTML specification</a></p>
</section>
</chapter></body></document>
1.1 jakarta-struts/doc/faqs/kickstart.xml
Index: kickstart.xml
===================================================================
<?xml version="1.0"?>
<document url="./kickstart.xml">
<properties>
<author>Ted Husted</author>
<author>Craig R. McClanahan</author>
<author>James DeVries</author>
<author>James Holmes</author>
<title>The Struts User's Guide - Kickstart FAQ</title>
</properties>
<body>
<chapter href="faq" name="Kickstart FAQ">
<section href="contents" name="Index">
<p>
Here are answers to the usual getting-started questions. <b>For an in-depth,
searchable FAQ, visit our friends at <a
href="http://www.jguru.com/faq/home.jsp?topic=Struts";>JGuru</a>.</b>
</p>
<ul>
<li><a href="#why">Why do we need Struts?</a></li>
<li><a href="#how">How does Struts work?</a></li>
<li><a href="#compat">Is Struts compatible with other Java technologies?</a></li>
<li><a href="#who">Who wrote Struts?</a></li>
<li><a href="#struts">Why is it called Struts?</a></li>
<li><a href="#license">How is Struts licensed?</a></li>
<li><a href="#usage">Can Struts be used in a commercial application?</a></li>
<li><a href="#credits">Do I have to credit Struts on my own website?</a></li>
</ul><ul>
<li><a href="#where">Where can I get a copy of Struts?</a></li>
<li><a href="#install">How do I install Struts?</a></li>
<li><a href="#jar">When do I need the struts.jar on my classpath?</a></li>
<li><a href="#tests">Does Struts provide its own unit tests?</a></li>
</ul><ul>
<li><a href="#help">Where can I get help with Struts?</a></li>
<li><a href="#consultants">Is commercial support available for Struts?</a></li>
<li><a href="#hosts">Are there ISPs that will host my Struts
application?</a></li>
<li><a href="#powered">What Web sites are already Powered by Struts?</a></li>
</ul><ul>
<li><a href="#turbine">What's the difference between Struts and Turbine?</a></li>
<li><a href="#taglibs">Why aren't the Struts tags maintained as part of the
Jakarta Taglibs project?</a></li>
<li><a href="#xhmtl">Are the Struts tags XHTML compliant?</a></li>
<li><a href="#jsf">What about the JSTL and JavaServer Faces?</a></li>
</ul><ul>
<li><a href="#digest">Is there a digest for the mailing list?</a></li>
<li><a href="#newsgroup">Is there a Struts Newsgroup?</a></li>
<li><a href="#mailbounce">Why didn't my posting show up on the user
list?"</a></li>
<li><a href="#unsubscribe">How do I unsubscribe from the mailing list?</a></li>
</ul><ul>
<li><a href="#more">Are there any other FAQs?</a></li>
</ul>
</section>
<section href="why" name="Why do we need Struts?">
<p>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.</p>
</section>
<section href="how" name="How does Struts work?">
<p>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.</p>
</section>
<section href="javasoft" name="Is Struts compatible with other Java technologies?">
<p>Yes. Struts is committed to supporting industry standards. Our lead developer is
a member of <a
href="http://java.sun.com/aboutJava/communityprocess/jsr/jsr_052_jsptaglib.html";>JSR052</a>,
Sun's Expert group for developing a standard library of custom JSP tags. A primary
design criteria is that Struts must be compatible with Sun's J2EE platform for
corporate enterprises. In fact, Struts really acts as an integrator of Java
technologies, so that they can be used in the "real world".</p>
</section>
<section href="who" name="Who wrote Struts?">
<p>Struts was created by Craig R. McClanahan, and donated to the Apache Software
Foundation in May 2000. Craig is the primary developer of both Struts and <a
href="http://jakarta.apache.org/tomcat/index.html";>Tomcat 4</a>, the basis for the
official reference implementation for a servlet 2.3 and JSP 1.2 container. With stable
releases of Struts and Tomcat 4 in circulation, Craig is now the Specification Lead
for <a href="http://jcp.org/jsr/detail/127.jsp";>JavaServer Faces (JSR-127)</a>, and is
the Web Layer Architect for the Java2 Enterprise Edition (J2EE) platform as a
whole.</p>
<p>There are now many active committers to the Struts project, working cooperatively
from around the globe. Other Java developers are invited to <a
href="#contribute">contribute to the project</a>. Struts is an <a
href="http://jakarta.apache.org/";>Apache Jakarta</a> project, with the common mission
to "provide commercial-quality server solutions based on the Java Platform that
are developed in an open and cooperative fashion". All told, 17 individual
developers and committers contributed to the Struts 1.0 codebase.</p>
</section>
<section href="struts" name="Why is it called Struts?">
<p>It's a reference to struts in the architectural sense, a reminder of the nearly
invisible pieces that hold up buildings, houses, and bridges.</p>
</section>
<section href="license" name="How is Struts licensed?">
<p>Struts is copyrighted software available under a "free-to-use-license"
by the Apache Software Foundation. The license appears at the head of every source
code file. A reference copy of the license is available <a
href="http://www.apache.org/LICENSE-1.1";>here</a>.</p>
</section>
<section href="usage" name="Can Struts be used in a commercial product?">
<p>Yes. The only requirements you must meet are those listed in the Apache Software
Foundation license, which is included at the top of each source file and in the file
LICENSE in the top-level directory of the distribution.</p>
<p>In addition, <a href="helping.html#bugs">contributions of patches, improved code,
new features,</a> or even just requests for features are also welcome.</p>
</section>
<section href="credits" name="Do I have to credit Struts on my own website?">
<p>You need to credit Struts if you <strong>redistribute your own framework</strong>
based on Struts
for other people to use. (See the <a href="http://www.apache.org/LICENSE";>Apache
License</a> for details.)
But you do <strong>not</strong> 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.
Required if you've used the source code to create your own server that you are
redistributing to other people.</p>
</section>
<section href="where" name="Where can I get a copy of Struts?">
<p>The best place to download Struts is at <a
href="http://jakarta.apache.org/struts/";>jakarta.apache.org/struts</a>. The nightly
builds are very stable, and recommended as the best place to start today.</p>
</section>
<section href="install" name="How do I install Struts?">
<p>To develop applications with Struts, you can usually just add the Struts JAR file
to your Java development environment. You can then start using the Struts classes as
part of your own application. A blank Struts application (in the
<code>webapps</code> directory, open <code>struts-blank.war</code>)
is provided, which you can just copy to get a quick-start on your own brainchild.</p>
<p>Since the full source code for Struts is available, we also provide
<a href="http://jakarta.apache.org/struts/installation.html";>complete
instructions</a>
for compiling your own Struts JAR from scratch. (This is actually easier than it
looks!)</p>
<p>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
<a href="http://jakarta.apache.org/struts/installation.html#Containers";>various
servlet
containers</a> are available.</p>
</section>
<section href="jar" name="When do I need "struts.jar" on my classpath?">
<p>When you are compiling an application that uses the Struts classes, you must have
the "struts.jar" on the classpath your <b>compiler</b> sees -- it does not
<i> have</i> to be on your CLASSPATH environment variable.</p>
<p>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" <b>must not</b> 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.)</p>
<p>There are several general approaches to this issue:</p>
<ul>
<li><b>Use ANT</b> 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).</li>
<li><b>Use an IDE</b> where you can configure the "class path" used for compilation
independent of the CLASSPATH environment variable.</li>
<li><b>Use a shell script</b> that temporarily adds struts.jar to the classpath
just for compilation, for example<br/>
<i>javac -classpath /path/to/struts.jar:$CLASSPATH $@</i></li>
</ul>
</section>
<section href="tests" name="Does Struts include its own unit tests?">
<p>
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.</p>
<p>
For static unit tests, we use the <a href="http://www.junit.org";>JUnit framework</a>.
The sources for these tests are in the "src/test"
hierarchy in the CVS 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 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.</p>
</section>
<section href="help" name="Where can I get help with Struts?">
<p>The Struts package comes complete with a
<a href="http://jakarta.apache.org/struts/userGuide/index.html";>Users Guide</a> 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
<a href="http://jakarta.apache.org/struts/api/index.html";>Javadocs</a> are included
along with the <b>full source code</b>. For your convenience, these are bundled
together as
a self-installing application. The <code>struts-documentation.war</code> is the same
bundle that is deployed as the
<a href="http://jakarta.apache.org/struts/";>Struts Web site</a>.
</p>
<p>
The
<a href="http://jakarta.apache.org/site/mail.html";>Strut's mailing list</a> is also
very active, and welcomes posts from new users. Before posting a new question, be
sure to consult the
<a href="http://www.mail-archive.com/struts-user%40jakarta.apache.org/";>
<b>MAILING LIST ARCHIVE</b></a> and the very excellent
<a href="http://www.tuxedo.org/~esr/faqs/smart-questions.html";>
How To Ask Questions The Smart Way</a> by Eric Raymond. Please do be sure
to <a href="http://expita.com/nomime.html";>turn off HTML</a> in your
email client before posting.
</p>
<p>
There are also many third-party tutorials, articles, and books that cover Struts.
See our
<a href="resources/tutorials.html">Resources page</a> for current listings and
links.
</p>
</section>
<section href="support" name="Is commercial support available?">
<p>There is no official, commercial support for Struts, though third parties may
offer different degrees of support. A list of Struts consultants is available on our
<a href="resources/consultants.html">Resources page</a></p>
</section>
<section href="providers" name="Are there ISPs that will host my Struts
application?">
<p>For a listing of some Java and Struts ISPs, visit our <a
href="resources/hosts.html">Resources page</a>.</p>
</section>
<section href="powered" name="What Web sites are already Powered by Struts?">
<p>For a listing of some Struts-powered Web sites available to the public, visit our
<a href="resources/powered.html">Resources page</a>.</p>
</section>
<section href="turbine" name="What's the difference between Jakarta Struts and
Jakarta Turbine?">
<p>See</p>
<ul>
<li>< <a
href="http://www.mail-archive.com/struts-user@;jakarta.apache.org/msg03206.html">http://www.mail-archive.com/struts-user@;jakarta.apache.org/msg03206.html</a>
></li>
<li>< <a
href="http://www.mail-archive.com/general@;jakarta.apache.org/msg00495.html">http://www.mail-archive.com/general@;jakarta.apache.org/msg00495.html</a>
></li>
<li>< <a
href="http://jakarta.apache.org/velocity/ymtd/ymtd.html";>http://jakarta.apache.org/velocity/ymtd/ymtd.html</a>
></li>
</ul>
</section>
<section href="taglibs" name="Why aren't the Struts tags maintained as part of the
Jakarta Taglibs project?">
<p>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 Java ServerPages Standard Taglib is in active
development. Once work on the JSPTL stabilizes, the Struts taglibs will be revisited.
Tags which are not linked directly to the framework may be hosted at Jakarta Taglibs
instead.</p>
</section>
<section href="xhtml" name="Are the Struts tags XHTML compliant?">
<p>If you utilize a <html:html xhtml="true> element on your page, the tags
will render in a XHTML compatible manner (since Struts 1.1 beta 2). </p>
</section>
<section href="wml" name="Will the Struts tags support other markup languages such
as WML">
<p>
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.
</p>
<p>Markup extensions that use Struts are available for
<a href="http://jakarta.apache.org/velocity";>Velocity</a> and
<a href="http://www.openroad.ca/opencode/";>XLST</a>, among others.
A new Struts tag for
<a href="#jsf">Java Server Faces</a> is also in development.
</p>
<p>For more about using WAP/WML with Struts see the article
<a href="http://www.sys-con.com/pbdj/archives2/0904/hamboeck/";>
WAP up your EAserver</a>.
</p>
</section>
<section href="jsf" name="What about the JSTL and JavaServer Faces?">
<p>
The lead developer of Struts, Craig McClanahan, was a member of the
expert group for the JavaServer Standard Tag Library (JSR 052) and
now the specification lead for JavaServer Faces (JSR 127). Both
technologies are complementary to Struts.</p>
<p>
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 as the
bundled JSP tags. This would apply to both the JSTL and JSF.</p>
<p>
At some point, we would not be surprised to see Faces become the
preferred UI implementation technology once it is standardized and
available. You can be assured that any future migration will be
made as painless as possible, and maximize your investment in
Struts.</p>
<p>
The JSTL is available through the Jakarta Taglibs site: <br/>
<a
href="http://jakarta.apache.org/taglibs/doc/standard-doc/intro.html";>http://jakarta.apache.org/taglibs/doc/standard-doc/intro.html</a>
</p>
<p>
The JavaServer Faces specification is still being finalized. Public release of
the specification is scheduled for Summer 2002, and an implementation may be
available in Fall of 2002. <a
href="http://servlet.java.sun.com/javaone/sf2002/conf/sessions/display-1697.en.jsp";>
A presentation was given at JavaOne 2002</a> with some additional background.
</p>
<p>
In September 2002, McClanahan announced that a
<a href="../proposals/struts-faces.html">struts-faces taglib</a> is in
development and might be released sometime in the Q4 2002. The taglib depends
on unreleased JSF features, and so an early release of the taglib must follow
release of a later implementation of JSF.
</p>
</section>
<section href="digest" name="Is there a digest for the User list?">
<p>
Yes. <a href="mailto:struts-user-digest-subscribe@;jakarta.apache.org">send a blank
message</a> to < <a
href="mailto:struts-user-digest-subscribe@;jakarta.apache.org">[EMAIL PROTECTED]</a>>.
</p>
<p>
If you are subscribed to the digest, you can also post to the list.
Just be sure to send your post to the
<a href="mailto:struts-user@;jakarta.apache.org">user list</a> rather than trying to
reply to the digest.
</p>
</section>
<section href="newsgroup" name="Is there a Struts newsgroup?">
<p>
Not a usenet group, but the Struts User list can be accessed with your
favorite newsgroup reader from the
<a href="http://news.basebeans.com/forums.jsp";>
BaseBeans Engineering</a> site.
</p>
</section>
<section href="mailbounce" name="Why didn't my posting show up on the user list?">
<p>
You must be subscribed to the <a
href="mailto:struts-user-subscribe@;jakarta.apache.org">user list</a>
or <a href="mailto:struts-user-digest-subscribe@;jakarta.apache.org">user digest</a>
before posting
(or use the <a href="http://news.basebeans.com/forums.jsp";>BaseBeans newsgroup</a>
instead).
</p>
</section>
<section href="unsubscribe" name="How do I unsubscribe from the mailing list?">
<p>
<b>From the email account used to subscribe to the list,</b> <a
href="mailto:struts-user-unsubscribe@;jakarta.apache.org">send a blank message</a> to
< <a
href="mailto:struts-user-unsubscribe@;jakarta.apache.org">[EMAIL PROTECTED]</a>>.
</p>
<p>
If you are receiving the digest, you must send a blank email to
<<a
href="mailto:struts-user-digest-unsubscribe@;jakarta.apache.org">[EMAIL PROTECTED]</a>>
instead.
</p>
</section>
</chapter></body></document>
1.1 jakarta-struts/doc/faqs/index.xml
Index: index.xml
===================================================================
<?xml version="1.0" encoding="ISO-8859-1"?>
<document url="./index.xml">
<properties>
<author>Ted Husted</author>
<title>FAQs and Howtos - Jakarta Struts</title>
</properties>
<body>
<section name="Struts FAQs and Howtos">
<ul>
<li><a href="kickstart.html">Kickstart FAQ</a> (read me first)</li>
<li><a href="newbie.html">Newbie FAQ</a> </li>
<li><a href="helping.html">How to Help FAQ</a> </li>
</ul>
<ul>
<li><a href="ssl.html">SSL Howto</a></li>
</ul>
</section>
<section name="Offsite FAQs and Howtos">
<ul>
<li><a href="http://www.jguru.com/faq/home.jsp?topic=Struts";>jGuru FAQ</a></li>
</ul>
<ul>
<li><a href="http://www.husted.com/struts/tips";>Struts Tips</a></li>
</ul>
</section>
</body></document>
1.1 jakarta-struts/doc/faqs/helping.xml
Index: helping.xml
===================================================================
<?xml version="1.0"?>
<document url="./helping.xml">
<properties>
<author>Ted Husted</author>
<author>Craig R. McClanahan</author>
<title>The Struts User's Guide - How to Help FAQ</title>
</properties>
<body>
<chapter href="faq" name="How to Help FAQ">
<section href="contents" name="Index">
<p>
<font face="Arial, Helvetica, sans serif">"You can't always get what you want / but
if you try real hard / you might just find /
that you get what you need". </font><br/>
[Rolling Stones]
</p>
<ul>
<li><a href="#corp">What can my company do to help support Struts?</a></li>
<li><a href="#bugs">How can I report bugs or make feature requests?</a></li>
<li><a href="#contribute">How can I contribute to Struts source code?</a></li>
<li><a href="#documentation">How can I contribute to the documentation?</a></li>
<li><a href="#release">So when is the next release coming out?</a></li>
<li><a href="#release_help">How can I help the next release along?</a></li>
</ul>
</section>
<section href="corp" name="What can my company do to help support Struts?">
<p>
Struts is an all volunteer product. Our customers are the volunteers who donate
their time and energy to supporting the product. If you want to support Struts, and
become one of our customers, then you need to
<a href="http://jakarta.apache.org/site/getinvolved.html";>get involved</a> and
become a volunteer.
</p>
<p>
Our challenge to any team using Struts is to donate the time of one team member one
afternoon a week (or more if you can spare the resources). Have your team member
browse Bugzilla for any
issues without a <a href="#code">patch</a> or <a href="#tests">unit test</a>, and
add the patch or test.
If the patch is written on company time, and you want to give your company an
author's credit, that's
fine with us.
</p>
<p>
If Struts doesn't do what <i>you</i> want, it's up to <b>you</b> to step up and
propose the patch.
If Struts doesn't ship as often as you would like, it's up to you to step up with
the tests and fixes that
get a release out the door.
</p>
<p>
If Struts does do what you want, help others become involved by turning your war
stories into FAQs and
how-tos that we can make part of the <a href="documentation">documentation</a>. The
mailing list is very
active and trundling through the archives is no picnic. We can always use people who
can reduce the best
threads to coherent articles that we can put in the User Guide.
</p>
<p>
We don't sell Struts for money, but anyone who wants to be our customer can pay us
back by donating
the time and energy that money represents.
</p>
</section>
<section href="bugs" name="How can I report bugs or make feature requests?">
<p>
You can research and report outstanding fixes and feature requests using
<a href="http://jakarta.apache.org/site/bugs.html";>Jakarta Bugzilla</a>. If you
are unsure if this is an actual problem, feel free to bring it up the list
first. But to sure that an issue is resolved, read
<a href="http://www.chiark.greenend.org.uk/~sgtatham/bugs.html";>How to Report
Bugs Effectively</a> and report it to
<a href="http://jakarta.apache.org/site/bugs.html";><b>Bugzilla</b></a>.
</p>
<p>
Feature requests are also maintained in the Bugzilla database. Some older
requests are still listed the <a href="../todo-1.1.html">wish list</a>
page.
</p>
<p>
<a href="http://jakarta.apache.org/site/source.html";>Patches</a> are always
welcome. If you can't write a patch to fix your bug, a <a href="#tests">unit test</a>
that demonstrates the problem is also welcome.
(And, of course, unit tests that prove your patch work are equally
welcome.)
</p>
<p>
If your bug or feature is already in Bugzilla, <strong>you can vote</strong>
for the issue and call more attention to it. Each user can cast up to six
votes at a time.
</p>
<p>
If there is a patch attached to the issue, you can also try applying
to your local copy of Struts, and report whether it worked for you.
Feedback from developers regarding a proposed patch is really quite
helpful. Don't hesitate to "me too" if you've tried the patch yourself.
</p>
</section>
<section href="contribute" name="How can I contribute to the Struts source code?">
<p>
Struts is distributed by the <a href="http://apache.org/";>Apache Software
Foundation</a>.
These are the same people who distribute the Apache Web server. Like all ASF
projects, Struts
is managed as a "meritocracy", where everyone's contribution is welcome.
Users can
help other users the <a href="http://jakarta.apache.org/site/mail.html";>mailing
lists</a>,
<a href="http://jakarta.apache.org/site/bugs.html";>report bugs</a>, and
<a href="http://jakarta.apache.org/site/bugs.html";>request new features</a>.
Developers can
contribute patches, new code, and documentation. The most active Developers may
become
<a href="http://jakarta.apache.org/site/roles.html";>Committers</a>, who make the
actual
decisions about Strut's codebase.
</p>
<p>
If you are new to open source development, see the
"<a href="http://jakarta.apache.org/site/getinvolved.html";>How to get involved</a>"
page the main Jakarta site.
</p>
<p>
A very good place to start is by <b>reviewing the list of open issues</b> and pending
feature requests (<a href="#bugs">Bugzilla</a>). If you see an issue that needs a
patch you can write, feel free to annex your patch. If you seen an issue that needs
a unit test to prove its fixed, feel free to annex your test case. If someone has
posted a
patch to an issue you'd like to see resolved, apply the patch to your local
development copy
of Struts. Then let us know if it works for you, and if it does, cast your vote for
the
issue and its patch.
</p>
<p>
If none of the pending issues scratch your itch, another good place to start is by
<b>contributing unit tests</b> for existing features (even those that still work).
</p>
<p>
Our current approach to <a href="kickstart.html#tests">unit testing</a>
works fairly well for exercising most method-level stuff, but does
not really address situations of dynamic behavior -- most particularly the
execution of custom tags for Struts. You can try to fake what a JSP
container does, but a much more reliable testing regime would actually
execute the tag in a real container. For that purpose, we use the
<a href="http://jakarta.apache.org/cactus";>Cactus</a>
testing framework , which re-executes
the JUnit-based tests as well to make sure that nothing bad happens when
you switch environments. Right now, there are very few dynamic tests;
ideally, we will have tests for every tag, that cover every reasonable
combination of tag attribute values (yes, that's a tall order -- the
totally lines of test source code will undoubtedly exceed the totally
lines of code in the framework itself if we achieve this).
</p>
</section>
<section href="documentation" name="How can I contribute to the documentation?">
<p>
The only difference is that the documentation is kept in XML rather than Java
source code. Otherwise, all the same precepts and procedures pertain.
</p>
<p>
The trick to getting started is to download the nightly build and try
building the documentation WAR. Then try adding your own XML page under doc/ to see
if the build succeeds. If it doesn't, it will report where the bad element is, much
like it reports where a bad programming expression is. If it does, then your page
should available under target/documentation/.
</p>
<p>
The website portion of the package is the root directory of doc/. The User Guide
portion is under the userGuide/ folder. If the material you'd to add doesn't
fit right in with what's there, the best thing may to start a new section after
the existing material. The navigation column can found in the project.xml document.
</p>
<p>
To display markup, substitute &lt; for <. The unmatched trailing > will
ignored. Since it is XML, all elements also need to closed. So elements like
<br> and <hr> need to set out as <br/> and <hr/>.
</p>
<p>
Also watch for the length of code samples. These do not wrap. If a line is too long,
it will force the right margin out past the edge of the screen or printed page.
</p>
<p>
The stylesheets we use are adequate, but could certainly improved by an XML
guru, if you happen to one of those.
</p>
</section>
<section href="release" name="So when is the next release coming out?">
<p>
Here is the truth regarding releases:
</p>
<p>
Jakarta products are released the basis of merit, and ~not~ according
to a strict timetable. The volunteers devote whatever time they can to working
the product. But all volunteers have real jobs and real lives, that
do take precedence. Since Struts does not have paid personnel working
the project, we simply cannot make date-oriented commitments.
</p>
<p>
All Jakarta products must circulate a public beta before release. If a
beta is not in circulation, then it's a good bet that a release is not
forthcoming any time soon. Products sometimes go through several betas
before final release. So if this is beta 1, then it still may not
released any time soon.
</p>
<p>
The bottom line is that Jakarta takes releases very seriously. We do not
compromise the quality of our software by watching the calendar (and
then ship something ready or not). A release is ready when it is ready.
</p>
<p>
That may sound flip, but it ~is~ the truth. The delivery of
production-quality, leading-edge software is not something anyone can
prognosticate. If anyone tries, they are lying to you. That, we won't
do ;-)
</p>
<p>
What we ~will~ do is release all of our development software as soon as it
is developed. This way you can judge for yourself how quickly the
development is proceeding, and whether what is being developed will meet
your needs. If you need a feature right now, you can use the nightly
build, or roll your own patch. There are no private CVS's or private
development lists. What you see is what we got. If you are following the
DEV list, then you know everything the developers know. Really, you do.
</p>
<p>
<i>So, what do you tell your team?</i> If you can ship your application based
the nightly build of your choice, then consider that an option. You can
still ship yours, even if we don't ship ours, and you will have access to
all the latest patches or enhancements. (Just like we were working down
the hall.) If you can only ship your application based a release build of
Struts, then you should base your development the release build of Struts,
and keep an eye what is coming down the pipeline. This way you are at least
forewarned and forearmed.
</p>
</section>
<section href="release_help" name="What can I do to help the next release along?">
<ul>
<li>
Most importantly, <b>download the latest beta</b> or release-candidate and test
it against your own applications. Report any and all issues or suspected issues
to <a href="http://jakarta.apache.org/site/bugs.html";>Bugzilla</a>. The sooner
we resolve any problems, the fewer betas or release candidates we will have to
distribute before we are done. (How do we know when we done? -- When we run out
of issues =:o) The sooner we find them, the sooner we are done.)
</li>
<li>
<b>Contribute <a href="kickstart.html#tests">unit tests</a></b>. The closer we get
to a release, the more we worry about breaking something. The more tests we have,
the
more confident we can when applying patches. Tests that proves that a pending
issue is actually a bug are the most welcome. But we are eager for any and all
tests
for any and all features, even those that still work =:0).
</li>
<li>
<b>Review the list of issues</b> at <a href="#bugs">Bugzilla</a>. If there are any
to which you can respond, please do. If there any patches posted, feel free to
test the
patch your system, report the results, and cast your vote if it works.
</li>
<li>
<b>Confirm an issue's category and status</b>. Newbies often post feature requests
or help-desk questions as "bugs". This bloats the list of fixes we (apparently)
need to
apply before the next beta, making it hard to see the forest for the trees. If an
issue
doesn't seem to categorized correctly, exercise your best judgment and change it.
If one ticket seems like a duplicate of another, go ahead and enter the change.
Every
modification to the ticket is echoed to the DEV list and automatically subjected to
peer review. Err on the side of doing.
</li>
<li>
Use Bugzilla to <b>vote for issues</b> you feel should be handled
first. If an issue on your ballot doesn't include a patch, feel free to try coding
one yourself. (At Jakarta, patches are the only votes that truly count.) Well over
<a href="volunteers.html">thirty developers</a> have contributed code or
documentation to the product. You can too =:0)
</li>
<li>
<b>Answer questions on the user list.</b> The Committers only have so much time to
volunteer. If Developers are supporting each other on the lists, the
Committers have more time to spend on the next release.
</li>
</ul>
</section>
<section href="decisions" name="Who makes the final decisions regarding Struts">
<p>
The management of the Jakarta site, and the Struts product, is based on principles
and
practices used by creators of the Apache HTTPD server. Struts follows the
<a href="http://jakarta.apache.org/site/guidelines.html";>Project Guidelines</a> on
the
main Jakarta site.
</p>
<p>If you are new to this style of development, the Apache HTTPD Dev list is
available in a
<a href="[EMAIL PROTECTED]">digest form</a>. Even if you are not
working on the HTTPD server yourself, it is interesting to watch how the HTTPD team
works on the server.
</p>
<p>
The Struts project has its own <a href="index.html#lists">Dev list</a>, where all of
the decisions regarding Struts are made. Most development takes place via
"<a href="http://jakarta.apache.org/site/proposal.html#decisions/voting/items";>Lazy
Consensus</a>".
Committers post most changes to the product unilaterally, using their own best
judgment,
and only discuss or vote upon controversial matters. Another Committer can veto any
change in an
unreleased product with cause.
</p>
</section>
</chapter>
</body>
</document>
--
To unsubscribe, e-mail: <mailto:struts-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@;jakarta.apache.org>
