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-...@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-unsubscr...@james.apache.org
For additional commands, e-mail: server-dev-h...@james.apache.org
