jwebmail-guide.html

Java编程 使用javamail 实现邮件管理系统

        Most developers will skip many of these steps because they probably
        already have some of the components in place.
        <OL>
          <LI>Install a 1.5 or later JDK and set a Windows env. variable for
            JAVA_HOME, with value of the absolute path to your JDK
            installation root.
            You can download a JDK from
            <A HREF="http://java.sun.com/javase/">Sun</A>.
          </LI> <LI>
            Install or have deployment access to a 2.4-spec-compliant servlet
            container like
            <A HREF="http://tomcat.apache.org/">Tomcat</A> version 6.
            (Could be installed on a different computer).
          </LI> <LI>
            Install a JDT variant of Eclipse, version 3.4.1 or later.
            I prefer the plain <I>Java</I> package, because it doesn't
            include tons of stuff that you will never use, like the much
            larger distributions have.
            After you extract the distribution, execute the startup binary
            once with the <CODE>-initialize</CODE> switch.
          </LI> <LI>
            To install Subversive, the Subversion client plugin,
            use pulldown menu <CODE>Help / Software Updates</CODE> and click
            the <CODE>Install</CODE> button.
            Bring up a web browser at the same time and browse to
            <A HREF="http://www.polarion.com/products/svn/subversive.php?src=eclipseproject">
    http://www.polarion.com/products/svn/subversive.php?src=eclipseproject</A>.
            Back in Eclipse, click the <CODE>Available Software</CODE> tab 
            and Add the two "required" URLs listed in the "Latest Release"
            section of that web page.
            Select the latest available release of each of the four following
            items and install them.<UL>
              <LI>SVN Team Provider</LI>
              <LI>JDT Ignore Extensions</LI>
              <LI>Connectors / Subversive SVN Connectors</LI>
              <LI>Connectors / SVNKit</LI>
            </UL>
            When done, you will be prompted to restart Eclipse.  Do so.
          </LI> <LI>
            After Eclipse restarts, use pulldown menu <CODE>File / Import</CODE>
            and import from Subversion.
            Enter URL of <CODE>https://jwebmail.svn.sourceforge.net/svnroot/jwebmail/trunk</CODE>
            and no other detals (unless you're a team developer).
            If it craps out, restart Eclipse and retry... or it could be a
            bad Internet connection to Sourceforge.
          </LI> <LI>
            Get rid of any Eclipse views that you don't need.
            Use pulldown <CODE>Window / Show View / Ant</CODE>.
            Click the target icon in the Ant view toolbar to hide internal
            Ant targets.
            Right click in the view and add the Ant build file
            <CODE>build.xml</CODE> from the root directory of the project.
            At this point all of the listed Ant targets should work,
            except for <CODE>gen-guide</CODE> and <CODE>all</CODE>, if you
            don't have <CODE>xsltproc</CODE> installed.
            Double click on <CODE>jwebmail</CODE> to execute the default target,
            which builds the war file.
            You will probably also want to execute the target
            <CODE>javadoc</CODE> to build the JWebMail API spec docs with
            entry point of <CODE>build/apidocs/index.html</CODE>.
          </LI> <LI>
            Now you just need to get IDE compilation working, and cooperating
            with the Ant build.
            Go to <CODE>Preferences / General / Workspace</CODE> to turn
            <CODE>Build automatically</CODE> off and <CODE>Refresh</CODE>
            and <CODE>Save</CODE> on.
          </LI> <LI>
            Use pulldown <CODE>Project / Clean...</CODE> to clean just
            the <CODE>jwebmail</CODE> project...
            and turn off the nasty <CODE>Start a build immediately</CODE>
            button (definitely a bad thing for shared Ant setups).
          </LI> <LI>
            Execute the ant target <CODE>eclipse-setup</CODE> and set the
            build variable as you instructed in the console output.
          </LI> <LI>
            Anybody who will be contributing code to this project, or to any
            other project with professional standards should read the next
            section too.
          </LI>
        </OL>
      </P>
    <A HREF="#install:ide">Top of section "IDE Setup"</A><A HREF="#install:intro">Top of section "Installing"</A><HR>
<A NAME="install:ide"></A><H2>3.4. IDE Code Contributors</H2>
<P>
        People contributing code to the JWebMail project must create code
        that isn't difficult for other developers to work with, and must
        commit resources in a way that doesn't clobber other workers.
        Even if you aren't going to commit code to our project,
        you're welcome to use these procedures if you just like developing
        like a professional, or if you are sharing with somebody else.
      </P>
<P> <OL>
        <LI>
          Even though you are a graphical developer, you need to read
          and understand the development rules above in the
          <CODE>Build and Install from source</CODE> section bove.
        </LI> <LI>
          Back to eclipse.
          A general tip is to be liberal with hitting <CODE>Apply</CODE>
          and <CODE>OK</CODE> when changing Eclipse preferences.
          It's much better now than with older versions, but Eclipse is known
          to sometimes <I>not get</I> your changes.
          If that happens, just repeat and make sure you apply.
          Back to the task at hand, go to
          <CODE>Windows / Preferences / Team / SVN / Properties Configuration</CODE>
          and Import the file <CODE>samples/config-svn.txt</CODE>.
          This file has specifically been massaged to do what it needs to do
          while accommodating several serious parsing bugs in the Eclipse
          Subversive plugin.
        </LI> <LI>
          The remaining items all involve importing Eclipse XML Java
          style profiles.
          <CODE>Window / Preferences / Java / Code Style</CODE>
          First, go to the <CODE>Clean Up</CODE> and Import the file
          <CODE>samples/cleanup-ecpro.xml</CODE>.
        </LI> <LI>
          Go to the <CODE>Formatter</CODE> and Import the file
          <CODE>samples/formatter-ecpro.xml</CODE>.
          Note that this formatter disabled word-wrapping for Java files,
          because Eclipse does a truly terrible job at it.
          It doesn't even enforce the rules as it explains and exemplifies them.
          Sorry to say, but after running Eclipse's code formatter, you'll
          need to apply word-wrapping manually (according to
          <CODE>doc/conventions.txt</CODE>.
          (The formatter works perfectly well for Javadoc and non-Javadoc
          comments).
        </LI> <LI>
          Finally, go to <CODE>Code Templates</CODE>, but this time don't
          load the profile at the global level.
          That's because, whereas the other settings are good for any
          Java project, these templates may not be appropriate for other
          Java projects that you may work on in the same Eclipse workspace.
          The only known issues with the code templates is that they will
          insert useless blank Javadoc lines like "    *" if there are no
          tags for a method, and it will insert a blank line after {'s and
          before }'s.
        </LI> <LI>
          Click on the <CODE>Configure Project Specific Settings...</CODE>.
          Select the <CODE>jwebmail</CODE> project and click <CODE>OK</CODE>.
          Click the <CODE>Enable project specific settings</CODE> checkbox.
          Import the file <CODE>samples/codetemplates-ecpro.xml</CODE>.
        </LI> <LI>
          In the upper tree, select <CODE>Comments / Types</CODE> and hit
          the <CODE>Edit...</CODE> button.
          (IMO it's rather counterintuitive that the lower box there is not
          an editable box-- you must hit the <CODE>Edit...</CODE> button to
          edit.
          Change the text "Your Name Here" to your name, spelled out and
          capitalized like that.
        </LI> <LI>
          Before exiting the <CODE>Properties for jwebmail...</CODE> screen,
          make sure to check the <CODE>Automatically add comments...</CODE>
          button and click the <CODE>Apply</CODE> and <CODE>OK</CODE> buttons.
        </LI>
      </OL>
</P>
<A HREF="#install:ide">Top of section "IDE Code Contributors"</A><HR>
<A NAME="install:logging"></A><H2>3.5. Logging setup</H2>
<P>
        Webapp logging is best administered at the container level.
        Most servlet containers were designed to work this way, and many
        technology companies expend much effort to defeat Classloader
        design and manage logging with delivered application artifacts.
        Remember that logging settings are a runtime consideration which
        should be modifiable after deployment by operations personnel.
        JWebMail is exceptional in that it facilitates logging
      </P>
<P>
        Webapp bundles just Apache Commons Logging.
        Commons Logging provides the front end for logging, where the
        JWebMail application sends log messages.
        Your servlet container will connect these generated messages to
        a logging <I>back end</I> to write log files, database records, or
        emails from them.
        If you have a straight-forward servlet container, and you have
        not added a logging product to it, then Commons Logging will
        also handle the back end in the container space, just logging
        to the console or stdout/stderr log with default settings.
        But it is very easy to improve on that.
        Some application servers have logging management utilities,
        and you can use them to pipe the JWebMail log entries to
        destinations using Gui tools or text files.
        You'll have to see your App Server documentation about these
        tools.
        Otherwise, you can put text files in container-level classloader
        directories to easily set up text, HTML, and even email-alert
        logging.
      </P>
<P>
        I will explain how to set up really nice JWebMail logs using
        Log4J as the back end (container-side) logging product on
        Tomcat.  In my experience, everybody is satisfied with Log4j.
        The procedure is very much the same to use another logging
        back end product (see the Commons Logging documentation about
        how to do it).  The setup procedure is the same for other
        servlet containers (that don't force their logging management
        system on you), except you just need to find out where the
        system classpath directories are (or how to add them).
      </P>
<P>Container logging setup with Log4j and Tomcat<UL>
        <LI>
          The default container classpath directory on Tomcat 6.x
          is <CODE>CATALINA_HOME/lib</CODE> by default.
          I.e., the "lib" subdirectory
          of the Tomcat installation root directory.
          You can put both Jar files and in .class files (in package
          directory trees) into it.
          (You can add other classpath directories by changing the
          setting <CODE>common.loader</CODE> in the file
          <CODE>conf/catalina.properties</CODE>).
        </LI> <LI>
          Copy a recent version of the file
          <A HREF="">
          log4j.jar</A> into the servlet container classpath directory.
        </LI> <LI>
          Copy a recent version of the file
          <A HREF="">
          admc-log4j.jar</A> into the servlet container classpath directory.
        </LI> <LI>
          Copy the file <CODE>log4j.xml</CODE> from the samples directory
          of your JWebMail distribution into the servlet container classpath directory.
        </LI> <LI>
          Set the Java System Property <CODE>logdir.common</CODE> for Tomcat.
          Our <CODE>log4j.xml</CODE> file uses this variable to set the
          destination directory for log files independently of where Tomcat
          is started from.  The best way to set Java System Properties for
          Tomcat is by setting the environmental variable CATALINA_OPTS.
          Where to set this variable depends on how you start Tomcat.
          If you use one of Tomcat's startup scripts directly on the
          command-line, then set the variable according to these samples.
          On Windows,
          <P><CODE>
              CATALINA_OPTS="-Djava.awt.headless=true -Xms512m -Xmx1024m -XX:MaxPermSize=256m -Dlogdir.common=$HOME/logs"
          </CODE></P>
          On Unix,
          <P><CODE>
              set CATALINA_OPTS=-Djava.awt.headless=true -Xms512m -Xmx1024m -XX:MaxPermSize=256m -Dlogdir.common=c:/logs
          </CODE></P>
          The samples shows unrelated settings which are often useful.
          See the Tomcat docs for details about them.
        </LI> <LI>
          Restart Tomcat.
        </LI>
      </UL>
        If you prefer working with .properties files instead of .xml files,
        you can make a <CODE>log4j.properties</CODE> file instead.
        See the Log4j documentation about how to set up email alerts
        with the SMTP appender, how to log to a database, etc.
      </P>
<P>
        Be aware that the file (<CODE>log4j.xml</CODE> or
        <CODE>log4j.properties</CODE>) will control all messages which
        reach Log4j in the container space.
        If you have three other web apps deployed to this container without
        log4j jar files bundled, their log messages will also be filtered
        by this file.
      </P>
<P>
        Regardless of the container and logging product, if you manage
        logging at the container level without a Gui, the server classpath
        file will be the central point of application log management for
        the container.
        You can use package names to route messages to application-specific
        destinations (files, emails, etc.).
        The only tricky part of container-managed logs is routing messages
        initiated by classes common to more than one webapp.
        This isn't the place to discuss how to route such messages, but
        you generally don't have to worry about it if your app catches all
        throwables, and you have the same app deployed more than
        once-at-a-time.
      </P>
<A HREF="#install:logging">Top of section "Logging setup"</A><HR>
<A HREF="#install">Top of section "Installation"</A><A NAME="config"></A><TABLE WIDTH="100%" BGCOLOR="#a0d895" CELLSPACING="0" BORDER="0"><TR><TD><H1><CENTER>IV. Configuration</CENTER></H1></TD></TR></TABLE>
<P>
      JWebMail has an administration interface which allows you to perform
      several runtime administration tasks, including:
      <UL>
        <LI>Changing all configuration settings</LI>
        
        <LI>Adding, deleting or editing JWebMail virtual domains</LI>
        <LI>Adding, deleting or editing JWebMail users</LI>
        <LI>Getting status information</LI>
      </UL>
      See the JWebMail Administrator Plugin section for details.