bloritsch    2002/12/19 09:44:06

  Added:       docs/developing compatiblity.html
  Log:
  update site to fix broken link
  
  Revision  Changes    Path
  1.1                  jakarta-avalon-site/docs/developing/compatiblity.html
  
  Index: compatiblity.html
  ===================================================================
  <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" 
"http://www.w3.org/TR/html4/loose.dtd";>
  <html><head><META http-equiv="Content-Type" content="text/html; 
charset=ISO-8859-1"><link rel="stylesheet" href="skin/tigris.css" 
type="text/css"><link rel="stylesheet" href="skin/site.css" 
type="text/css"><link media="print" rel="stylesheet" href="skin/print.css" 
type="text/css"><meta value="Avalon Documentation Team" name="author"><meta 
value="avalon-dev@jakarta.apache.org" name="email"><title></title></head><body 
bgcolor="white" class="composite" marginheight="0" marginwidth="0"><div 
id="banner"><table width="100%" cellpadding="8" cellspacing="0" 
border="0"><tbody><tr><td align="left"><a 
href="http://jakarta.apache.org/";><img border="0" 
src="images/jakarta-logo.gif"></a></td><td align="right"><a 
href="http://jakarta.apache.org/avalon/";><img border="0" 
src="images/header.gif"></a></td></tr></tbody></table></div><table width="100%" 
cellpadding="0" cellspacing="0" border="0" id="breadcrumbs"><td><a 
href="http://jakarta.apache.org/";>Jakarta Main</a> |
              <a href="http://jakarta.apache.org/avalon";>Avalon Main</a> |
              <a href="../">Up</a></td><td style="text-align: right" 
align="right"><a 
href="http://jakarta.apache.org/avalon/framework/";>Framework</a> |
              <a 
href="http://jakarta.apache.org/avalon/excalibur/";>Excalibur</a> |
              <a 
href="http://jakarta.apache.org/avalon/cornerstone/";>Cornerstone</a> |
              <a href="http://jakarta.apache.org/avalon/phoenix/";>Phoenix</a> |
              <a href="http://jakarta.apache.org/avalon/apps/";>Apps</a> |
              <a 
href="http://jakarta.apache.org/avalon/logkit/";>Logkit</a></td></table><table 
id="main" width="100%" cellpadding="8" cellspacing="0" border="0"><tbody><tr 
valign="top"><td id="leftcol"><div 
id="navcolumn"><div><strong>About</strong><div><a href="index.html">Book 
Info</a></div><div><a 
href="changes.html">Revisions</a></div></div><div><strong>Chapters</strong><div><a
 href="introduction.html">Overview</a></div><div><a 
href="decomposing.html">Decomposition</a></div><div><a 
href="framework.html">Avalon Framework</a></div><div><a 
href="implementing.html">Using the framework</a></div><div><a 
href="compatiblity.html">Compatibility with Avalon</a></div><div><a 
href="conclusion.html">Conclusion</a></div></div><div><strong>Printer 
Friendly</strong><div><a href="developing-with-avalon.pdf">As a 
PDF</a></div></div></div></td><td><div id="bodycol"><div class="app"><div 
align="center"><h1></h1><h2></h2></div><div class="h3"><center><table 
width="100%"><tr><td bgcolor="#99aabb"><center><b><font 
face="arial,helvetica,sanserif" color="#000000" size="+2">Compatibility with 
Avalon Project 
Containers</font></b></center></td></tr></table></center><br><font 
color="#525D76" face="arial,helvetica,sanserif"><i>
      How to make your project compatible with an Avalon Containers.
    </i></font><br><font face="arial,helvetica,sanserif" color="#000000"><p 
align="justify">
      There are many applications, utility or tools written in Java that you 
      wish you could use in an Avalon container.  It may be that you are 
      writing such an app/utility/tool that you intend to additionally be 
      usable by Avalon components in Avalon containers.  This document 
      gives some advice on the subject.  We will refer to applications, 
      utilities and tools as just 'tools' from her on in.  We'll assume 
      the classes for which are in a single Jar.    
    </p><p align="justify">  
      This advise is applicable to all
      <a xmlns:xi="http://www.w3.org/2001/XInclude"; 
href="../framework/reference-containers.html">reference containers</a>
    </p></font><br><div align="right"><table cellspacing="0" cellpadding="2" 
border="0" width="100%"><tr><td bgcolor="bbccdd"><font 
face="arial,helvetica,sanserif" color="#000000" size="+1"><b>Making a Jar for a 
tool</b></font></td></tr><tr><td><font face="arial,helvetica,sanserif" 
color="#000000"><br>
      
      <p align="justify">
        The tool's Jar should only contain the classes in question and 
        directly associated resources. It should not contain the classes 
        or resources from other projects.  For example it is a bad habit 
        to include the org.apache.xerces.* jars in another jar.  It would 
        be correct for the notes accompanying the tools to list xerces.jar 
        as a dependency.
      </p>
      <p align="justify"> 
        It is best that packages for the tool are well defined.  Sun 
        recommend a package structure that honors the internet domain of 
        the hosted proejct.  For example org.apache prefixes all the packages
        of projects hosted at Apache.  Sometimes a project thinks it is 
        significant enough to avoid the domain name based naming, but still 
        have a package.  JUnit is an example of this, as it uses junit as its 
        top level package.  Tools that have no package or a package name
        that a non unique word are not good design.
      </p>
    </font></td></tr></table></div><br><div align="right"><table 
cellspacing="0" cellpadding="2" border="0" width="100%"><tr><td 
bgcolor="bbccdd"><font face="arial,helvetica,sanserif" color="#000000" 
size="+1"><b>Wrapping third party tools</b></font></td></tr><tr><td><font 
face="arial,helvetica,sanserif" color="#000000"><br>
      
      <p align="justify">
        There are many tools written in Java as beans that you wish you could 
        use in an Avalon container as a component.  If they are not 
        dependent on Avalon packages and classes already it is likely that 
        some wrapper concept is appropriate.  The normal form is to have 
        a separate package with a class that is dependent on Avalon Framework 
        methods.  That wrapper class would be Configurable, Initializable etc, 
        and would map its configuration to setZYZ() methods in the original 
bean.
      </p>
      <p align="justify">
        It is also a good idea to understand the 
        <a xmlns:xi="http://www.w3.org/2001/XInclude"; 
href="../framework/guide-patterns-soii.html">separation of interface 
        and implementation</a> when designing components.
      </p>
    </font></td></tr></table></div><br><div align="right"><table 
cellspacing="0" cellpadding="2" border="0" width="100%"><tr><td 
bgcolor="bbccdd"><font face="arial,helvetica,sanserif" color="#000000" 
size="+1"><b>Dynamic Classloading</b></font></td></tr><tr><td><font 
face="arial,helvetica,sanserif" color="#000000"><br>
      
      <p align="justify">
        Many Java tools internally use 
        <em>Class.forName(String).newInstance()</em> 
        to instantiate some part of its internal functionality.  This
        works if the class's Jar is mounted at the top-level system 
        classloader.  In the case of many Avalon containers, the Jar in 
        question will actually be mounted in a classloader at some other point
        in a tree of classloaders.  Thus <em>Class.forName()</em> 
        will fail with ClassNotFoundException if running in a container.  
      </p>
      <p align="justify">
        A better thing to do would be to use 
        <em>this.getClass().getClassLoader().loadClass(String)</em>.
        This means that the class will always be loaded from classloader
        that hosts the rest of the classes for the tool.  It can run at any
        point in a tree of classloaders without problem.
      </p>
    </font></td></tr></table></div><br><div align="right"><table 
cellspacing="0" cellpadding="2" border="0" width="100%"><tr><td 
bgcolor="bbccdd"><font face="arial,helvetica,sanserif" color="#000000" 
size="+1"><b>Use of Static</b></font></td></tr><tr><td><font 
face="arial,helvetica,sanserif" color="#000000"><br>
      
      <p align="justify">
        It is common amongst novice developers to use much static 
        functionality.  This could be methods or class variables.  Given 
        that Avalon's containers may mount multiple instances of a component
        potentially in multiple classloaders, the use of static may lead to
        unpredicted behavior.  If the static var or method is mounted in a 
        classloader that is visible to multiple components, then it will 
        behave as expected.  For this reason, static should be used with care 
        - you cannot guarantee where someone might try to run your tool.
      </p>
      <p align="justify">
        Static also makes Unit Testing quite difficult.  If you can at all 
        avoid it, please do so.
      </p>
    </font></td></tr></table></div><br><div align="right"><font size="-2" 
face="arial,helvetica,sanserif" 
color="#000000"><p></p></font></div></div></div></div></td></tr></tbody></table><div
 id="footer"><table width="100%" cellpadding="4" cellspacing="0" 
border="0"><tbody><tr><td align="left">Copyright &copy; 1999-2002 Apache 
Software Foundation. All Rights Reserved.</td><td></td><td 
align="right"><script language="JavaScript">
                            <!--
                                    document.write("last modified: " + 
document.lastModified);
                            //  -->
  
                             
</script></td></tr></tbody></table></div></body></html>
  
  

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to