struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From craig...@apache.org
Subject cvs commit: jakarta-struts/doc/userGuide configuration.xml
Date Mon, 20 Jan 2003 00:03:22 GMT
craigmcc    2003/01/19 16:03:22

  Modified:    doc/userGuide configuration.xml
  Log:
  Add a sidebar to discourage people from putting struts.jar and commons-*.jar
  in a container's "shared JARs" repository.
  
  Revision  Changes    Path
  1.15      +88 -0     jakarta-struts/doc/userGuide/configuration.xml
  
  Index: configuration.xml
  ===================================================================
  RCS file: /home/cvs/jakarta-struts/doc/userGuide/configuration.xml,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- configuration.xml	19 Jan 2003 00:40:41 -0000	1.14
  +++ configuration.xml	20 Jan 2003 00:03:22 -0000	1.15
  @@ -1116,6 +1116,94 @@
       for how to avoid copying the tlds into your application.
       </p>
   
  +    <div align="center">
  +      <table border="1" cellspacing="0" cellpadding="5" width="80%">
  +      <tr><td bgcolor="cyan">
  +
  +      <h3 align="center">
  +        Sidebar:  Sharing JAR Files Across Web Applications
  +      </h3>
  +
  +      <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.
  +          <blockquote>
  +            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.
  +          </blockquote>
  +        </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).
  +          <blockquote>
  +            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.
  +          </blockquote>
  +        </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>
  +      </td></tr>
  +      </table>
  +    </div>
  +
   </section>
   
   <section
  
  
  

--
To unsubscribe, e-mail:   <mailto:struts-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:struts-dev-help@jakarta.apache.org>


Mime
View raw message