Author: akarasulu Date: Wed Dec 15 08:44:51 2004 New Revision: 111995 URL: http://svn.apache.org/viewcvs?view=rev&rev=111995 Log: Changes ...
o corrected navigation links o added submenus o added more content o creating new pages for backend subsystem and networking layers Added: incubator/directory/eve/trunk/xdocs/developers/backend.xml incubator/directory/eve/trunk/xdocs/developers/networking.xml Modified: incubator/directory/eve/trunk/xdocs/developers/architecture.xml incubator/directory/eve/trunk/xdocs/developers/index.xml incubator/directory/eve/trunk/xdocs/developers/navigation.xml incubator/directory/eve/trunk/xdocs/users/plugin.xml Modified: incubator/directory/eve/trunk/xdocs/developers/architecture.xml Url: http://svn.apache.org/viewcvs/incubator/directory/eve/trunk/xdocs/developers/architecture.xml?view=diff&rev=111995&p1=incubator/directory/eve/trunk/xdocs/developers/architecture.xml&r1=111994&p2=incubator/directory/eve/trunk/xdocs/developers/architecture.xml&r2=111995 ============================================================================== --- incubator/directory/eve/trunk/xdocs/developers/architecture.xml (original) +++ incubator/directory/eve/trunk/xdocs/developers/architecture.xml Wed Dec 15 08:44:51 2004 @@ -8,7 +8,7 @@ <body> <section name="High Level Architecture"> <subsection name="A picture is worth a thousand words!"> - <img src="./images/architecture.png"/> + <img src="../images/architecture.png"/> <p> Eve is actually composed of two separable subsystems: the LDAP protocol Added: incubator/directory/eve/trunk/xdocs/developers/backend.xml Url: http://svn.apache.org/viewcvs/incubator/directory/eve/trunk/xdocs/developers/backend.xml?view=auto&rev=111995 ============================================================================== --- (empty file) +++ incubator/directory/eve/trunk/xdocs/developers/backend.xml Wed Dec 15 08:44:51 2004 @@ -0,0 +1,120 @@ +<?xml version="1.0" encoding="UTF-8"?> +<document> + <properties> + <author email="[EMAIL PROTECTED]">Alex Karasulu</author> + <title>Backend Subsystem</title> + </properties> + + <body> + <section name="Backend Subsystem"> + <p> + The backend subsystem is everything minux the networking layer and the + protocol handling layer. It is composed of several parts in itself: the + JNDI provider, interceptor framework, schema subsystem, and database + subsystem. Each sub-subsystem of the backend is described in the + sections to follow. + </p> + + + <subsection name="Database Subsystem"> + <p> + The overall design to the database subsystem is described to some + degree within the partition documentation which can be found + <a href="../users/partition.html">here</a>. In summary this subsystem + is responsible for storing and accessing entries addressed by DN. + </p> + + <p> + Eventually we intend to delve into the design of the database + subsystem by breaking down the search engine, optimizer and default + backing store design which uses JDBM BTrees. + </p> + + <p> + For future reference below the RootNexus is the top level object or + facade of the database subsystem. It contains all context partitions + and routes calls to them based on the location of the context within + the namespace. + </p> + </subsection> + + + <subsection name="JNDI Provider"> + <p> + The JNDI Provider is just an implementation of the + InitialContextFactory, Context, and other derived interfaces. The + factory is used to fire up the entire server if it has not been + started already to service the JNDI request. The contexts are simple + wrappers around the database subsystem which point to a specific entry + withing the namespace. More will be put here as time progresses ... + </p> + </subsection> + + + <subsection name="Interceptor Framework"> + <p> + Calls to the RootNexus are made from within Context implementations + of the JNDI provider. Relative Context positions or names are + translated into (absolute) distinguished names and the appropriate + call is made on the RootNexus. The calls are intercepted using a + proxy and additional functionality is injected before, after and on + exception to calls made on the RootNexus. + </p> + + <p> + A framework is built around this. The Context, parameters, return + values and any exceptions that may be thrown by the call are + encapsulated within an Invocation object. This object is passed to + a chain of interceptors that operate on the values it holds to + implement a service. + </p> + + <p> + There are three separate types or stages of interceptors. + Interceptors can operate before a method invocation, after an + invocation and when an error results during any point in this process. + Separate chains of interceptors have been created for each stage. The + Invocation object is passed through this chain and each interceptor + operates upon it. + </p> + + <p> + Not all interceptor chains are created equally! The before and after + chains are fail fast. Meaning the processing of an Invocation object + shorts the rest of the chain if one interceptor fails while processing + the invocation. This is not the case when processing exceptions in + the on error interceptor chain. Regardless of an interceptor's + success downstream, all interceptors are guaranteed a chance to + operate on the Invocation object. This makes the on-error chain an + excellent place to put cleanup code or code to handle failures. + </p> + + <p> + When implementing a cross cutting service with the interceptor + framework one or more interceptors may be added to one or more + chains. Keep in mind this framework helps inject new functionality + but it can get conjested very quickly. + </p> + </subsection> + + + <subsection name="Schema Subsystem"> + <p> + The schema subsystem manages LDAP schema objects. These objects + have a direct effect on how lookups and search operations are + conducted on the directory. The subsystem contains a set of + registries for each type of LDAP schema object based on OID. + </p> + + <p> + Schema objects may reference one another by OID and so the system + is designed to dynamically resolve dependent objects by lookups on + these registries. + </p> + </subsection> + + + </section> + + </body> +</document> Modified: incubator/directory/eve/trunk/xdocs/developers/index.xml Url: http://svn.apache.org/viewcvs/incubator/directory/eve/trunk/xdocs/developers/index.xml?view=diff&rev=111995&p1=incubator/directory/eve/trunk/xdocs/developers/index.xml&r1=111994&p2=incubator/directory/eve/trunk/xdocs/developers/index.xml&r2=111995 ============================================================================== --- incubator/directory/eve/trunk/xdocs/developers/index.xml (original) +++ incubator/directory/eve/trunk/xdocs/developers/index.xml Wed Dec 15 08:44:51 2004 @@ -18,10 +18,55 @@ <tr> <td> - <a href="/index.html">Developer's Guide</a> + <a href="./architecture.html">Architecture</a> </td> <td> - Blah blah. + Eve's high level architecture. + </td> + </tr> + + <tr> + <td> + <a href="./components.html">Components</a> + </td> + <td> + How we do components in Eve. + </td> + </tr> + + <tr> + <td> + <a href="./networking.html">Networking</a> + </td> + <td> + Describes Eve's networking layer. + </td> + </tr> + + <tr> + <td> + <a href="./protocol.html">Protocol</a> + </td> + <td> + The design of LDAP protocol layer. + </td> + </tr> + + <tr> + <td> + <a href="./backend.html">Backend Subsystem</a> + </td> + <td> + Looks at the backend subsystem design in detail. + </td> + </tr> + + <tr> + <td> + <a href="./.html"></a> + </td> + <td> + </td> </tr> Modified: incubator/directory/eve/trunk/xdocs/developers/navigation.xml Url: http://svn.apache.org/viewcvs/incubator/directory/eve/trunk/xdocs/developers/navigation.xml?view=diff&rev=111995&p1=incubator/directory/eve/trunk/xdocs/developers/navigation.xml&r1=111994&p2=incubator/directory/eve/trunk/xdocs/developers/navigation.xml&r2=111995 ============================================================================== --- incubator/directory/eve/trunk/xdocs/developers/navigation.xml (original) +++ incubator/directory/eve/trunk/xdocs/developers/navigation.xml Wed Dec 15 08:44:51 2004 @@ -27,9 +27,9 @@ <item name="Developer's Guide" href="/developers/index.html"> <item name="Architecture" href="/developers/architecture.html"/> <item name="Components" href="/developers/components.html"/> - <item name="Protocol" href="/developers/protocol.html"/> - <item name="JNDI Provider" href="/developers/provider.html"/> <item name="Networking" href="/developers/networking.html"/> + <item name="Protocol" href="/developers/protocol.html"/> + <item name="Backend Subsystem" href="/developers/backend.html"/> </item> <item name="Eve Projects" href="/projects/index.html"/> </menu> Added: incubator/directory/eve/trunk/xdocs/developers/networking.xml Url: http://svn.apache.org/viewcvs/incubator/directory/eve/trunk/xdocs/developers/networking.xml?view=auto&rev=111995 ============================================================================== --- (empty file) +++ incubator/directory/eve/trunk/xdocs/developers/networking.xml Wed Dec 15 08:44:51 2004 @@ -0,0 +1,64 @@ +<?xml version="1.0" encoding="UTF-8"?> +<document> + <properties> + <author email="[EMAIL PROTECTED]">Alex Karasulu</author> + <title>Ldap Protocol Provider</title> + </properties> + + <body> + <section name="Networking"> + <p> + We wanted to keep the networking code as independent as possible to + prevent it's concerns from creeping into the LDAP protocol handling + code. Furthermore we wanted it to be independent of the LDAP protocol + so it can be reused as much as possible with other protocols. + </p> + + <p> + This lead to the creation of a newtorking framework or two. These + frameworks use different approaches and models to provide the network + plumbing needed by internet protocol servers. A common protocol + provider API is used to implement protocols enabling the provider on + all network frameworks. + </p> + + <p> + Each network framework at the directory project has its own project so + its best to delegate a description of each framework to the appropriate + project documentation: + </p> + + <table> + <tr> + <th>Framework</th> <th>Description</th> + </tr> + + <tr> + <td><a href="../../seda/index.html">seda</a></td> + + <td> + A simple framework for implementing staged event driven internet + protocol servers. + </td> + </tr> + + <tr> + <td><a href="../../seda/index.html">sedang</a></td> + + <td> + The next generation seda framework. + </td> + </tr> + + <tr> + <td><a href="../../mina/index.html">mina</a></td> + + <td> + . + </td> + </tr> + </table> + </section> + + </body> +</document> Modified: incubator/directory/eve/trunk/xdocs/users/plugin.xml Url: http://svn.apache.org/viewcvs/incubator/directory/eve/trunk/xdocs/users/plugin.xml?view=diff&rev=111995&p1=incubator/directory/eve/trunk/xdocs/users/plugin.xml&r1=111994&p2=incubator/directory/eve/trunk/xdocs/users/plugin.xml&r2=111995 ============================================================================== --- incubator/directory/eve/trunk/xdocs/users/plugin.xml (original) +++ incubator/directory/eve/trunk/xdocs/users/plugin.xml Wed Dec 15 08:44:51 2004 @@ -81,39 +81,35 @@ </table> </subsection> - <subsection name="Goals"> - <p> - <goals> - <goal> - <name>eve:generate</name> - <description> - Generates class files for OpenLDAP schemas. - </description> - </goal> - <goal> - <name>eve:init</name> - <description> - Finds the required parameters needed for the goals of the - plugin. - </description> - </goal> - <goal> - <name>eve:prepare-filesystem</name> - <description> - Creates source output directories used to deposite schema - files that are generated. - </description> - </goal> - <goal> - <name>eve:schema</name> - <description> - Top level schema generating function that uses other goals to - coordinate generation. - </description> - </goal> - </goals> - </p> - </subsection> + <goals> + <goal> + <name>eve:generate</name> + <description> + Generates class files for OpenLDAP schemas. + </description> + </goal> + <goal> + <name>eve:init</name> + <description> + Finds the required parameters needed for the goals of the + plugin. + </description> + </goal> + <goal> + <name>eve:prepare-filesystem</name> + <description> + Creates source output directories used to deposite schema + files that are generated. + </description> + </goal> + <goal> + <name>eve:schema</name> + <description> + Top level schema generating function that uses other goals to + coordinate generation. + </description> + </goal> + </goals> <subsection names="Usage"> <p>
