configuration.html

struts api,学习使用struts必备的文档

    path part) with a particular value to be passed to this servlet.
    Such an entry might look like this:
    </p>

<pre>
<code>
&lt;servlet-mapping&gt;
    &lt;servlet-name&gt;action&lt;/servlet-name&gt;
    &lt;url-pattern&gt;/do/*&lt;/url-pattern&gt;
&lt;/servlet-mapping&gt;
</code>
</pre>

        <p>
        which means that a request URI to match the <code>/logon</code> path
        described earlier might look like this:
        </p>

<pre>
<code>http://www.mycompany.com/myapplication/do/logon</code>
</pre>

        <p>
        where <code>/myapplication</code> is the context path under which your
        application is deployed.
        </p>

        <p>
        Extension mapping, on the other hand, matches request URIs to the
        action servlet based on the fact that the URI ends with a period
        followed by a defined set of characters.
        For example, the JSP processing servlet is mapped
        to the <code>*.jsp</code> pattern so that it is called to process
        every JSP page that is requested.
        To use the <code>*.do</code> extension (which implies "do something"),
        the mapping entry would look like this:
        </p>

<pre>
<code>
&lt;servlet-mapping&gt;
    &lt;servlet-name&gt;action&lt;/servlet-name&gt;
    &lt;url-pattern&gt;*.do&lt;/url-pattern&gt;
&lt;/servlet-mapping&gt;
</code>
</pre>

        <p>
        and a request URI to match the <code>/logon</code> path described
        earlier might look like this:
        </p>

<pre>
<code>http://www.mycompany.com/myapplication/logon.do</code>
</pre>

        <p>
        <strong>WARNING</strong> - Struts will not
        operate correctly if you define more than one
        <code>&lt;servlet-mapping&gt;</code> element for the controller
        servlet.
        </p>

        <p>
        <strong>WARNING</strong> - If you are using
        the new module support since Struts 1.1, you should be aware
        that <strong>only</strong> extension mapping is supported.
        </p>

</div>
<h2 id="dd_config_taglib">5.4.3 Configure the Struts Tag Libraries</h2>
<div class="indent">

        <p>
        Next, you must add an entry defining the Struts tag libraries.
        </p>

        <p>
        The <a href="dev_bean.html">struts-bean</a> taglib contains tags useful in accessing beans and their
        properties, as well as defining new beans (based on these accesses)
        that are accessible to the remainder of the page via scripting
        variables and page scope attributes.
        Convenient mechanisms to create new beans based on the value of request
        cookies, headers, and parameters are also provided.
        </p>

        <p>
        The <a href="dev_html.html">struts-html</a> taglib contains tags used to create Struts input forms,
        as well as other tags generally useful in the creation of HTML-based
        user interfaces.
        </p>

        <p>
        The <a href="dev_logic.html">struts-logic</a> taglib contains tags that are useful in managing
        conditional generation of output text,
        looping over object collections for repetitive generation of output
        text,  and application flow management.
        </p>

        <p>
        The <a href="dev_tiles.html">struts-tiles</a> taglib contains tags used for combining various view
        components, called "tiles", into a final composite view.
        </p>

        <p>
        The <a href="dev_nested.html">struts-nested</a> taglib is an extension of other struts taglibs that
        allows the use of nested beans.
        </p>

        <p>
        Below is how you would define all Struts taglibs for use within your
        application.
        In practice, you would only specify the taglibs that your application
        uses:
        </p>

<pre>
<code>
&lt;taglib&gt;
     &lt;taglib-uri&gt;
     http://struts.apache.org/tags-bean
     &lt;/taglib-uri&gt;
     &lt;taglib-location&gt;
     /WEB-INF/struts-bean.tld
     &lt;/taglib-location&gt;
&lt;/taglib&gt;
&lt;taglib&gt;
     &lt;taglib-uri&gt;
     http://struts.apache.org/tags-html
     &lt;/taglib-uri&gt;
     &lt;taglib-location&gt;
     /WEB-INF/struts-html.tld
     &lt;/taglib-location&gt;
&lt;/taglib&gt;
&lt;taglib&gt;
     &lt;taglib-uri&gt;
     http://struts.apache.org/tags-logic
     &lt;/taglib-uri&gt;
     &lt;taglib-location&gt;
     /WEB-INF/struts-logic.tld
     &lt;/taglib-location&gt;
&lt;/taglib&gt;
&lt;taglib&gt;
     &lt;taglib-uri&gt;
     http://struts.apache.org/tags-tiles
     &lt;/taglib-uri&gt;
     &lt;taglib-location&gt;
     /WEB-INF/struts-tiles.tld
     &lt;/taglib-location&gt;
&lt;/taglib&gt;
&lt;taglib&gt;
     &lt;taglib-uri&gt;
     http://struts.apache.org/tags-nested
     &lt;/taglib-uri&gt;
     &lt;taglib-location&gt;
     /WEB-INF/struts-nested.tld
     &lt;/taglib-location&gt;
&lt;/taglib&gt;
</code>
</pre>

    <p>
    This tells the JSP system where to find the tag library descriptor
    for this library (in your application's <code>WEB-INF</code> directory, instead of
    out on the Internet somewhere).
    </p>

</div>
<h2 id="dd_config_taglib_23">5.4.3.1 Configure the Struts Tag Libraries (Servlet 2.3/2.4)</h2>
<div class="indent">

    <p>
    <strong>Servlet 2.3/2.4 users only:</strong> The Servlet 2.3 and 2.4 specifications simplify
    the deployment and configuration of tag libraries.
    The instructions above will work on older containers as well as 2.3 and 2.4
    containers (Struts only requires a servlet 2.2 container);
    however, if you're using a 2.3/2.4 container such as Tomcat 4.x/5.x,
    you can take advantage of a simplified deployment.
    </p>

    <p>
    All that's required to install the Struts tag libraries is to copy
    <code>struts.jar</code> into your <code>/WEB-INF/lib</code> directory and reference the tags in
    your code like this:
    </p>

    <pre>
<code>
    &lt;%@ taglib
        uri="http://struts.apache.org/tags-html"
        prefix="html" %&gt;
    </code>
</pre>

    <p>
    Note that you <strong>must use the full uri</strong> defined in the various
    tlds (see the <a href="#dd_config_taglib">example configuration</a> for reference)
    so that the container knows where to find the tag's class files.
    You don't have to alter your <code>web.xml</code> file or copy tlds into any
    application directories.
    </p>

</div>
<h2 id="config_add">5.5 Add Struts Components To Your Application</h2>
<div class="indent">

    <p>
    To use Struts, you must copy the .tld files that you require into
    your <code>WEB-INF</code> directory, and copy <code>struts.jar</code>
    (and all of the <code>commons-*.jar</code> files) into your
    <code>WEB-INF/lib</code> directory.
    </p>

    <p>
    <strong>Servlet 2.3/2.4 Users:</strong> See
    <a href="#dd_config_taglib_23">section 4.5.3.1</a>
    for how to avoid copying the tlds into your application.
    </p>

    <div class="notice">
      <h4 class="center">
        Sidebar:  Sharing JAR Files Across Web Applications
      </h4>

      <p>
        Many servlet containers and application servers provide facilities
        for sharing JAR files across multiple web applications that depend
        on them.  For example, Tomcat 4.1 allows you to put JAR files into
        the <code>$CATALINA_HOME/shared/lib</code> or
        <code>$CATALINA_HOME/common/lib</code> directories, and the classes
        in those JAR files will be available in all applications, without
        the need to place them in every web application's
        <code>/WEB-INF/lib</code> directory.  Usually, the sharing is
        accomplished by creating a separate class loader that is the parent
        of the class loader (created by your container) for each individual
        web application.
      </p>

      <p>
        If you have multiple Struts-based web applications, it is tempting
        to consider taking advantage of this container feature, and placing
        <code>struts.jar</code> and the various <code>commons-*.jar</code>
        files in the shared directory, rather than in each web application.
        However, there are several potential, and actual, problems with
        this approach:
      </p>

      <ul>
        <li>
          Classes loaded from the shared class loader cannot see classes
          in the web application's class loader, unless they are specifically
          programmed to use the Thread context class loader.

            For example, Struts dynamically loads your action and form bean
            classes, and normally would not be able to find those classes.
            Struts has been programmed to deal with this in <em>most</em>
            scenarios, but it has not been thoroughly audited to ensure that
            it works in <em>all</em> scenarios.  The Commons libraries that
            Struts uses have <strong>NOT</strong> been audited to catch all
            possible scenarios where this might become a problem.

        </li>
        <li>
          When a class is loaded from a shared class loader, static variables
          used within that class become global as well.  This can cause
          inter-webapp conflicts when the underlying code assumes that the
          statics are global only within a particular web applicaiton (which
          would be true if the class was loaded from the webapp class loader).

            There are many cases where Struts, and the Commons libraries it
            relies on, use static variables to maintain information that is
            presumed to be visible only within a single web applicaiton.
            Sharing these JAR files can cause unwanted interactions, and
            probably cause incorrect behavior.

        </li>
        <li>
          When JAR files are shared like this, it is not possible to update
          the JAR file versions employed by a single web application without
          updating all of them.  In addition, because updating a Struts version
          normally requires recompilation of the applications that use it,
          you will have to recompile all of your applications as well, instead
          of being able to manage them independently.
        </li>
      </ul>

      <p>
        In spite of these difficulties, it is possible that sharing the
        Struts and Commons JAR files <em>might</em> appear to work for you.
        However, this is <strong>NOT</strong> a supported configuration.
      </p>

      <p>
        If you file a bug report for <code>ClassNotFoundException</code> or
        <code>NoClassDefFoundError</code> exceptions, or similar situations
        where it appears that the wrong version of a class is being loaded,
        the bug report will <strong>NOT</strong> be processed unless the
        problem exists with the JAR files in their recommended location,
        in the <code>/WEB-INF/lib</code> subdirectory of your webapp.
      </p>
    </div>

</div>
<h2 id="config_logging">5.6 Logging in Struts Based Applications</h2>
<div class="indent">

  <p>
  Since Struts 1.0, the logging functionality was fairly limited.  You could
  set a debugging detail level with a servlet initialization parameter, and
  all log messages were written to wherever <code>ServletContext.log()</code>
  output is sent by your servlet container.  With Struts 1.1, however, all
  logging messages written by Struts itself, as well as the commons libraries
  that it utilizes, flow through an abstract wrapper called
  <a href="http://jakarta.apache.org/commons/logging">Commons Logging</a>,
  which can be used as a wrapper around any logging implementation.  The most
  common implementations used are simple logging to <code>System.err</code>,
  the <a href="http://jakarta.apache.org/log4j/">Apache Log4J</a> package,
  or the built-in logging capabilities of JDK 1.4 or later in the
  <a href="http://java.sun.com/j2se/1.4/docs/api/java/util/logging/package-summary.html">
  java.util.logging</a> package.
  </p>

  <p>
  This section does not attempt to fully explain how Commons Logging is
  configured and used.  Instead, it focuses on pertinent details of using
  Commons Logging in a Struts based environment.  For complete documentation
  on using Commons Logging, consult the documentation for the logging system
  you are using, plus the Commons Logging
  <a href="http://jakarta.apache.org/commons/logging/api/org/apache/commons/logging/package-summary.html#package_description">
  Javadocs</a>.
  </p>

  <p>
  Commons Logging provides fine-grained control over the logging messages
  created by a <code>Log</code> instance.  By convention, the <code>Log</code>
  instances for Struts (and the Commons packages in general) are named the
  fully qualified class name of the class whose messages are being logged.
  Therefore, log messages created by the <code>RequestProcessor</code> class are, naturally
  enough, directed to a logger named
  <code>org.apache.struts.action.RequestProcessor</code>.
  </p>

  <p>
  The advantage of this approach is that you can configure the level of detail
  in the output you want from each class, individually.  However, it would be
  a burden to be required to maintain such settings for every possible class,
  so the logging environment supports the notion of logging
  <em>hierarchies</em> as well.  If a detail level configuration for a
  particular class has not been set, the logging system looks up the hierarchy
  until it finds a configuration setting to use, or else uses the default
  detail level if no configuration for any level of the hierarchy has been
  explicitly set.  In the case of our messages from <code>RequestProcessor</code>,
  the logging system will look for explicit settings of the following loggers,
  in this order, until it finds one:
  </p>

  <ul>
  <li>
<code>org.apache.struts.action.RequestProcessor</code>
</li>
  <li>
<code>org.apache.struts.action</code>
</li>
  <li>
<code>org.apache.struts</code>
</li>
  <li>
<code>org.apache</code>
</li>
  <li>
<code>org</code>
</li>
  <li>The default logging detail level for your log implementation.</li>
  </ul>

  <p>
  In a similar manner, the detail level for messages from
  <code>PropertyUtils</code> (from the Commons BeanUtils library) is set by
  a search for configuration settings for:
  </p>

  <ul>
  <li>
<code>org.apache.commons.beanutils.PropertyUtils</code>
</li>
  <li>
<code>org.apache.commons.beanutils</code>
</li>
  <li>
<code>org.apache.commons</code>
</li>
  <li>
<code>org.apache</code>
</li>
  <li>
<code>org</code>
</li>
  <li>The default logging detail level for your log implementation.</li>
  </ul>

  <p>
  You can seamlessly integrate logging from your own components into the same
  logging implementation that Struts and the Commons libraries use, by
  following the instructions in
  <a href="building_controller.html#logging">Section 4.10</a>.  If you do
  this, you are strongly encouraged to follow the same naming convention for
  loggers (based on the class name of the messages being logged) for
  maximum configuration flexibility.
  </p>

</div>
<hr class="section" />
<div class="indent">

    <p>
    For more about putting it all together, see the <a href="../faqs/apps.html">
    Building Applications HowTo</a>.
    </p>

    <p class="right">
    Next: <a href="./release-notes.html">Release Notes</a>
    </p>

</div>
  </div>
<!--end main-->
</div>
<!--end content-->
<div id="footer">
<img id="powered-logo" alt="Powered by Struts" src="../images/struts-power.gif" />
        Copyright (c) 2000-2005, The Apache Software Foundation <span class="noprint">- 
        <a href="http://wiki.apache.org/struts/StrutsDocComments">Comments?</a>
</span>
</div>
<!--end footer-->
</body>
</html>