| <?xml version="1.0"?> |
| <document> |
| <properties> |
| <title>Jackrabbit Extension Framwork - Overview</title> |
| </properties> |
| <body> |
| <section name="Introduction"> |
| <p> |
| Jackrabbit, the Apache Group's open source implementation |
| of the Content Repository for Java Technology API (JSR |
| 170), will be the basis for a series of upcoming |
| products. Some are more integrated with Jackrabbit, like |
| the WebDAV server, some are plain applications of the Jakrabbit, |
| like for example a repository based content management system. |
| </p> |
| |
| <p>All of these applications share similar requirements:</p> |
| |
| <ul> |
| <li>Extensibility of some sort</li> |
| <li>Configuration requirements</li> |
| </ul> |
| |
| <p> |
| To address these common problems and to provide an easy |
| to use framework to jump start on this extensibility |
| issue without requiring tedious configuration steps at |
| different locations, this document proposes the Jackrabbit |
| Extension Framework. |
| </p> |
| |
| <p> |
| The core of the Jackrabbit Extension Framework is the |
| <code> |
| <a |
| href="apidocs/org/apache/jackrabbit/extension/ExtensionManager.html"> |
| org.apache.jackrabbit.extension.ExtensionManager |
| </a> |
| </code> |
| which provides the API to load and instantiate |
| extensions for further use. The basic concepts of |
| extensions are as follows: |
| </p> |
| |
| <ul> |
| <li> |
| An extension is part of a group ofextensions sharing |
| common functionality. Each such group is called an |
| extension type and has a name. That name, commonly |
| called the <i>extension type identification</i>, should |
| be unique within a single application. |
| There is no additional semantic bound to an |
| extension type identification. In fact the |
| uniqueness requirement is not enforced and it is the |
| sole responsibility of the administrator and/or |
| extension type implementor to make sure there are no |
| two extension types with the same identification. A |
| simple method to handle this issue is to apply the |
| same naming conventions as proposed by Sun for |
| <a |
| href="http://java.sun.com/docs/codeconv/html/CodeConventions.doc8.html#367"> |
| package names |
| </a> |
| . |
| </li> |
| <li> |
| Each extension has a unique name within the realm of |
| its extension type. Again, this requirement is not |
| enforced and it is the administrator's or |
| implementor's responsibility to guarantee this |
| uniqueness requirement. |
| </li> |
| <li> |
| An extension may be implemented by some Java code, |
| which should be loaded into the system for use. That |
| is, an extension has an associated class and |
| optionally a class path to indicated where to load |
| the Java classes from. To simplify deployment of |
| extensions the classes (or JAR archives) containing |
| the extension implementation together with optional |
| required libraries may be stored in the repository. |
| </li> |
| <li> |
| Often times extensions need to be provided with some |
| sort of configuration, which of course would also be |
| stored in the repository. |
| </li> |
| </ul> |
| |
| <p> |
| As a consequence of the above noted uniques requirements |
| for extension type identifications and extension names, |
| two instances of the |
| <code> |
| <a |
| href="apidocs/org/apache/jackrabbit/extension/ExtensionDescriptor.html"> |
| ExtensionDescriptor |
| </a> |
| </code> |
| class are considered equal if the have the same type |
| identification and name. |
| </p> |
| |
| <p> |
| See |
| <a href="examples/deployment.html">Deployment</a> |
| for a sample extension stored in the repository. |
| </p> |
| </section> |
| </body> |
| </document> |
