You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by er...@apache.org on 2011/04/07 17:11:58 UTC
svn commit: r1089909 - /james/server/trunk/src/site/xdoc/dev.xml
Author: eric
Date: Thu Apr 7 15:11:58 2011
New Revision: 1089909
URL: http://svn.apache.org/viewvc?rev=1089909&view=rev
Log:
Some more generic information on server development (JAMES-1219)
Modified:
james/server/trunk/src/site/xdoc/dev.xml
Modified: james/server/trunk/src/site/xdoc/dev.xml
URL: http://svn.apache.org/viewvc/james/server/trunk/src/site/xdoc/dev.xml?rev=1089909&r1=1089908&r2=1089909&view=diff
==============================================================================
--- james/server/trunk/src/site/xdoc/dev.xml (original)
+++ james/server/trunk/src/site/xdoc/dev.xml Thu Apr 7 15:11:58 2011
@@ -20,14 +20,14 @@
<document>
<properties>
- <title>Design Objectives</title>
+ <title>Develop on James</title>
<author email="site-dev@james.apache.org">James Project Web Team</author>
</properties>
<body>
<section name="Functional Architecture">
-
+
<p>James is a multi-protocol message processing and storage engine. James
currently consists of:
<ul>
@@ -48,7 +48,21 @@
<img src="images/uml/org.apache.james-package.png"/>
- <p>James is deployed on top of Spring, ActiveMQ, OpenJPA, Netty,...</p>
+ <p>James uses many other components: Spring, ActiveMQ, OpenJPA, Netty, Jackrabbit, Derby...</p>
+
+ <p>The modules can be classified into 3 categories:</p>
+ <ul>
+ <li>api: they does not include implementation details, they do not have dependencies (or at most they have very common dependencies like mailet-api, javamail, commons-logging).</li>
+ <li>library: they only depends on apis or external jars. They don't depend on other internal libraries. These libraries should be shared by functions (no need to have a library when it is used only by a function).</li>
+ <li>functions: everything else. It is harder to see a case of "direct" reuse of a function jar. Most times we'll only have code reuse. I would prefer to limit function to function dependencies.</li>
+ </ul>
+
+ <section name="Server Coding Guidelines">
+
+ <p>LogEnabled interface as the preferred way, except for non-server code and classes that have no bean definition.</p>
+ <p>LogEnabled should be used wherever logging is needed and no "session-scoped" Log is provided.</p>
+
+ </section>
</section>
@@ -58,20 +72,20 @@
<p>These are some of the currently implemented features:</p>
- <p><i><b>Complete portability</b></i> Apache James is be a 100% pure Java application
+ <p><i><b>Complete portability</b></i> Apache James is be a 100% pure Java application
based on the Java 2 platform and the JavaMail 1.4 API.</p>
- <p><i><b>Protocol abstraction</b></i> Unlike other mail engines, protocols are seen only
+ <p><i><b>Protocol abstraction</b></i> Unlike other mail engines, protocols are seen only
like "communication languages" ruling comunications between clients and
the server. Apache James is not be tied to any particular protocol but
follow an abstracted server design (like JavaMail did on the
client side)</p>
- <p><i><b>Complete solution</b></i> the mail system is able to handle both mail
+ <p><i><b>Complete solution</b></i> The mail system is able to handle both mail
transport and storage in a single server application. Apache James
works alone without the need for any other server or solution.</p>
- <p><i><b>Mailet support</b></i> Apache James supports the Apache Mailet API. A Mailet
+ <p><i><b>Mailet support</b></i> Apache James supports the Apache Mailet API. A Mailet
is a discrete piece of mail-processing logic which is incorporated into
a Mailet-compliant mail-server's processing. This easy-to-write,
easy-to-use pattern allows developers to build powerful customized mail
@@ -80,15 +94,15 @@
list manager, etc. Several Mailets are included in the James
distribution (see <a href="dev-provided-mailets.html">documentation</a>).</p>
- <p><i><b>Resource abstraction</b></i> Like protocols, resources are abstracted and,
- accessed through defined interfaces (JavaMail for transport, JDBC for
- spool storage or user accounts in RDBMS's, Apache Mailet API). The server is
- highly modular and reuse solutions from other projects.</p>
-
- <p><i><b>Secure and multi-threaded design</b></i> Based on well known
- frameworks such as Spring, ActiveMQ, OpenJPA, Netty,..., Apache James has a careful,
- security-oriented, full multi-threaded design, to allow performance,
- scalability and mission-critical use.</p>
+ <p><i><b>Resource abstraction</b></i> Like protocols, resources are abstracted and,
+ accessed through defined interfaces (JavaMail for transport, JDBC for
+ spool storage or user accounts in RDBMS's, Apache Mailet API). The server is
+ highly modular and reuse solutions from other projects.</p>
+
+ <p><i><b>Secure and multi-threaded design</b></i> Based on well known
+ frameworks such as Spring, ActiveMQ, OpenJPA, Netty,..., Apache James has a careful,
+ security-oriented, full multi-threaded design, to allow performance,
+ scalability and mission-critical use.</p>
<p>Anything else you may want if you help us write it :-)</p>
@@ -97,7 +111,7 @@
<subsection name="Standards Compliance">
<p>It is the existence of published "open" standards which
- allows independant teams to develop interoperable software.</p>
+ allows independant teams to develop interoperable software.</p>
<p>James attempts to support a number of these standards most of which are
IETF RFC's and in the areas covered by these standards the published standard
@@ -124,18 +138,18 @@
James.</p>
<p>In cases (like jira issue JAMES-344) where variance from a published standard is
- required it is desirable that this functionality is disabled in James by default,
- it must be prominently and clearly documented that this causes James
- to violate the relevant standard, and should be enabled by explicit
- configuration, making its use a conscious decision of the user rather
- than an decision taken by the James team.</p>
+ required it is desirable that this functionality is disabled in James by default,
+ it must be prominently and clearly documented that this causes James
+ to violate the relevant standard, and should be enabled by explicit
+ configuration, making its use a conscious decision of the user rather
+ than an decision taken by the James team.</p>
<p>In cases where the required behaviour is not within the scope of any standard which
- James claims to support (such as behaviour which is a de-facto standard or
- an <i>internet draft</i> RFC but not yet subject of a <i>standards track</i> RFC) it is
- acceptable to implement the behaviour so long as it is adequately
- documented (for instance by refrence to an <i>internet draft</i> or
- other public document) and users can be clear about what to expect from James.</p>
+ James claims to support (such as behaviour which is a de-facto standard or
+ an <i>internet draft</i> RFC but not yet subject of a <i>standards track</i> RFC) it is
+ acceptable to implement the behaviour so long as it is adequately
+ documented (for instance by refrence to an <i>internet draft</i> or
+ other public document) and users can be clear about what to expect from James.</p>
</subsection>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org