You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@jackrabbit.apache.org by ju...@apache.org on 2012/01/10 19:51:06 UTC
svn commit: r1229679 [2/12] - /jackrabbit/site/trunk/content/
Added: jackrabbit/site/trunk/content/concurrency-control.mdtext
URL: http://svn.apache.org/viewvc/jackrabbit/site/trunk/content/concurrency-control.mdtext?rev=1229679&view=auto
==============================================================================
--- jackrabbit/site/trunk/content/concurrency-control.mdtext (added)
+++ jackrabbit/site/trunk/content/concurrency-control.mdtext Tue Jan 10 18:50:59 2012
@@ -0,0 +1,416 @@
+Title: Concurrency control
+The internal concurrency model in Apache Jackrabbit is fairly complex and a
+number of deadlock issues have been reported and fixed over the Jackrabbit
+1.x release cycle. This document is the result of a design and code review
+targeted at proactively preventing other similar issues.
+
+This document is about the internal concurrency and synchronization model
+in Jackrabbit, _not_ about the JCR locking feature. Note that the review
+that led to this document targeted concurrency control at an architectural
+level and did not focus much on issues like thread-safety of individual
+classes or components.
+
+This review is based on Jackrabbit version 1.5 in default configuration.
+
+<a name="Concurrencycontrol-Architecturalbackground"></a>
+## Architectural background
+
+!arch.jpg|align=right! In terms of concurrency control, the Jackrabbit
+architecture can roughly be divided to five main layers:
+
+1. Cluster
+1. Repository
+1. Workspace
+1. Session
+1. Transaction
+
+The clustering layer takes care of synchronizing changes across one or more
+cluster nodes that are each treated as individual repositories that happen
+to share their content. Concurrency control across different cluster nodes
+is achieved using a single write lock that a cluster node is required to
+acquire before it can commit any changes to the shared state. On the other
+hand all cluster nodes can read the shared content in parallel with no
+explicit synchronization. Note that since the cluster nodes only share a
+single lock, a deadlock can not occur between the locks in one node and the
+ones in another. A single deadlocked node can still potentially block
+writes to the entire cluster, but the clustering feature can not add any
+new deadlock scenarios if each node would be deadlock-free by itself.
+
+The repository layer takes care of all global repository state like the
+node type registry and the version storage. Instead of a single global
+repository lock, all the repository-wide components have their own
+synchronization mechanisms. The most notable component from a concurrency
+control point of view is the version storage, that actually contains two
+locking mechanisms; one in VersionManagerImpl for high level versioning
+operations and one in the underlying SharedItemStateManager for controlling
+access to the underlying persistence mechanism.
+
+A repository consists of one or more workspaces that contain the normal
+content trees of the repository. Each workspace consists of a few
+components like the persistence mechanism and the search index. The
+persistence mechanism is built from a SharedItemStateManager that controls
+all item operations and a PersistenceManager that persists items in
+permanent storage. Most persistence managers use Java synchronization or
+some other locking mechanism for concurrency control, but since they
+typically don't interact much with other parts of the repository they are
+not that critical from a global concurrency perspective. On the other hand,
+the SharedItemStateManager that uses a read-write lock is a key element
+especially given the way it interacts with the repository-wide version
+store. Note that since Jackrabbit 1.4 it has been possible to configure
+locking strategy of the SharedItemStateManager to use a more fine-grained
+set of locks to allow concurrent write access to different parts of the
+content tree. This review focuses on the default case of having just a
+single SharedItemStateManager lock, but from a locking perspective the more
+fine-grained case is roughly equivalent to having more workspaces and thus
+the results of this review should still apply.
+
+Each workspace can be accessed by zero or more JCR sessions. Each session
+contains a transient space that keeps track of all unsaved changes in that
+session. Since the transient space is local to a session and since a
+session should only be accessed by one thread at a time, there are few
+concurrency concerns associated with the use of sessions. However, note
+that the thread-safety requirements of sessions are in many cases not
+explicitly enforced by Jackrabbit, so a client that intentionally or
+accidentally uses a single session from multiple concurrent threads may
+well end up corrupting the internal state of the session.
+
+Transactions are handled in Jackrabbit by wrapping all item operations
+(saved transient changes and direct workspace updates, as well as
+versioning and locking operations) into a sort of a larger transient space
+that gets persisted only when the transaction is committed. There is no
+"transaction lock" in Jackrabbit, but transaction support still
+fundamentally changes Jackrabbit concurrency control as it basically
+replaces all write operations (and related locking) with the larger commit
+operation. This transaction mode is only activated when a session is within
+the context of an XA transaction.
+
+<a name="Concurrencycontrol-Mainsynchronizationmechanisms"></a>
+## Main synchronization mechanisms
+
+!lock.jpg|align=right! The main synchronization mechanisms in Jackrabbit
+are the read-write locks in the SharedItemStateManager and
+VersionManagerImpl classes. Other components also have concurrency control
+features, for example the LockManagerImpl class (used for handling JCR
+locks) uses a reentrant lock and the NodeTypeRegistry class relies on Java
+synchronization. This review focuses on just the two main components as
+those are by far the most actively used and the ones that could potentially
+block all access to repository content in case of a deadlock. The three
+main locks to be concerned about are:
+
+ * "Workspace lock", the read-write lock of the per-workspace
+SharedItemStateManager
+ * "Versioning lock", the read-write lock of the repository-wide
+VersionManagerImpl
+ * "Version store lock", the read-write lock of the
+SharedItemStateManager associated with the version manager
+
+Each of these locks can be locked exclusively for write access or
+inclusively for read access. In other words, any number of concurrent
+readers can keep the lock, but any single writer will block out all other
+readers and writers.
+
+As noted in the section above, the workspace locks may also be collections
+of more finely grained locks, but this review concentrates on the default
+case. Note also that each workspace has it's own lock, so even if one
+workspace is exclusively locked, other workspaces can still be accessed.
+
+<a name="Concurrencycontrol-Conditionsfordeadlocks"></a>
+## Conditions for deadlocks
+
+A deadlock can only occur if the holder of one lock tries to acquire
+another lock and there is another thread (or a series of other threads)
+that tries to do the reverse. This situation can only arise if a) locks are
+acquired in a nested sequence, b) different threads can acquire the nested
+locks in a different order, and c) at least two exclusive locks are being
+acquired.
+
+Most operations in Jackrabbit avoid deadlocks in one of the following three
+ways:
+
+ * Only a single lock is held at a time, breaking condition a. This case
+covers most of the code doing sanity checks and other preparing work
+associated with many operations.
+ * In case of nested locks, the code guarded by the inner lock never
+tries to acquire another lock, breaking condition b. This case covers for
+example the numerous calls to the underlying persistence managers that
+typically have their own synchronization mechanism but never call out to
+other Jackrabbit components except perhaps the namespace registry that also
+satisfies this condition.
+ * None of the nested locks are exclusive. This covers all read
+operations in Jackrabbit, so a deadlock can never occur if all clients only
+read from the repository.
+
+The potentially troublesome cases are two or more concurrent write
+operations with nested locks, or a write operation with two nested
+exclusive locks running concurrently with read operations with nested
+locks. See below for the results of the code review that tried to identify
+and clear such cases. The acquired write locks are marked in bold to make
+it easy to spot potential problems.
+
+<a name="Concurrencycontrol-Codereview"></a>
+## Code review
+
+This section contains the results of a code review whose purpose was to
+identify the order and nesting of the locks acquired by many common
+operations in Jackrabbit. The results of the review were compared to the
+above conditions for deadlock.
+
+Note that the descriptions of the write operations below assume
+non-transactional context. See the last subsection for the behaviour in
+transactional environments.
+
+<a name="Concurrencycontrol-Normalreadaccess"></a>
+### Normal read access
+
+Read access to the workspace typically only requires a read lock on the
+SharedItemStateManager of that workspace, but since the version store is
+mapped to the virtual /jcr:system/jcr:versionStorage inside the repository,
+there are cases where also the read lock of the version store needs to be
+acquired.
+
+1. Workspace read lock, for reading normal node content
+1. # Version store read lock, for reading version content
+
+This nested lock is potentially unsafe in a transactional context, see the
+subsection on transaction commit below for more details.
+
+<a name="Concurrencycontrol-Versioningreadaccess"></a>
+### Versioning read access
+
+Some version accesses are handled directly through the version manager
+instead of looking through the /jcr:system/jcr:versionStorage tree. Such
+accessed are guarded with the VersionManagerImpl read lock.
+
+1. Versioning read lock, for accessing version information
+1. # Version store read lock, for reading version information
+
+The nested lock here is safe as the version store lock never covers code
+that tries to acquire the versioning lock.
+
+<a name="Concurrencycontrol-Transientchanges"></a>
+### Transient changes
+
+All transient changes like those created by Node.addNode() or
+Session.move() are stored in the session-local transient space without
+needing any synchronization except for the read locks used for accessing
+the underlying workspace state. A write lock is only needed when the
+accumulated changes are being persisted using the save() call described
+below.
+
+<a name="Concurrencycontrol-Save"></a>
+### Save
+
+The ItemImpl.save() method (that SessionImpl.save() also calls) collects
+all current transient changes to a single change log that is then persisted
+as an atomic update. Any new versionable nodes will cause empty version
+histories to be created in the version store. Note that ItemImpl.save() is
+synchronized on the current session, enforcing the rule that no two threads
+should be concurrently using the same session.
+
+1. Workspace read lock, for sanity checks and other preliminary work
+1. Multiple non-overlapping instances of (only when creating new version
+histories)
+1. # Workspace read lock, for checking the current state of the nodes
+being modified
+1. # Version store read lock, for checking whether a version history
+already exists
+1. # Versioning *write lock*, for creating a new version history
+1. ## Version store *write lock*, for persisting the version history
+1. Workspace *write lock*, for persisting the changes
+1. # Version store read lock, for checking references
+1. # Version store *write lock*, for persisting updated back-references
+
+Many of the other write operations below call ItemImpl.save() internally to
+persist changes in the current workspace. However, in the descriptions I've
+only included the last "Workspace write lock" branch (with the "Version
+store write lock" excluded if it's clear that no back-references need to be
+updated) as the operations are guaranteed to never contain cases where new
+version histories would need to be created.
+
+Here we have three cases of nested locks involving one or more exclusive
+locks:
+
+ * Versioning write lock -> Version store write lock
+ * Workspace write lock -> Version store read lock
+ * Workspace write lock -> Version store write lock
+
+All these nested locks are safe in non-transactional context since the
+version store lock never covers code that tries to acquire one of the other
+locks. The same is true for the first case also in transactional context,
+but see the transaction commit subsection below for a discussion of how the
+other two cases are different with transactions.
+
+<a name="Concurrencycontrol-Mergeandupdate"></a>
+### Merge and update
+
+The Node.merge() and Node.update() methods both call
+NodeImpl.internalMerge() that acquires a new session on the source
+workspace and copies relevant content to the current workspace.
+
+1. Multiple non-overlapping instances of
+1. # Source workspace read lock, for copying content to the current
+workspace
+1. # Current workspace read lock, for comparing current status with the
+one being merged
+1. Current workspace *write lock*, for persisting the changes
+1. # Version store read lock, for checking references
+1. # Version store *write lock*, for persisting updated back-references
+
+The nested locks above are discussed in the section on the save operation.
+
+<a name="Concurrencycontrol-Copy,cloneandmove"></a>
+### Copy, clone and move
+
+The various copy(), clone() and move() methods in WorkspaceImpl use the
+similarly called methods in BatchedItemOperations to perform batch
+operations within a single workspace or across two workspaces. From a
+synchronization perspective these operations are much like the merge and
+update operations above, the difference is mostly that the source workspace
+may be the same as the current workspace.
+
+1. Multiple non-overlapping instances of
+1. # Source workspace read lock, for copying content to the current
+workspace
+1. # Current workspace read lock, for comparing current status with the
+one being copied
+1. Current workspace *write lock*, for persisting the changes
+1. # Version store read lock, for checking references
+1. # Version store *write lock*, for persisting updated back-references
+
+The nested locks above are discussed in the section on the save operation.
+
+<a name="Concurrencycontrol-Checkin"></a>
+### Checkin
+
+The NodeImpl.checkin() method first creates a new version of the node in
+the shared version store and then updates the appropriate mix:versionable
+properties of the node.
+
+1. Workspace read lock, for sanity checks and other preliminary work
+1. Versioning *write lock*, for creating the new version in the version
+store
+1. # Workspace read lock, for copying content to the new version
+1. # Version store *write lock*, for persisting the new version
+1. Versioning read lock, for accessing the newly created version
+1. # Version store read lock, for reading the new version
+1. Workspace *write lock*, for updating the node with references to the
+new version
+1. # Version store read lock, for checking references
+1. # Version store *write lock*, for persisting updated back-references
+
+The overlapping lock region above is not troublesome as there are no cases
+where a versioning lock is acquired within the scope of a workspace lock.
+Note that there previously were such cases, but this code review shows that
+all of them have since been solved.
+
+The nested locks above are discussed in the sections on versioning read
+access and the save operation.
+
+<a name="Concurrencycontrol-Checkout"></a>
+### Checkout
+
+The NodeImpl.checkout() method simply does some sanity checks and updates
+the versioning metadata of the node to reflect the changed state. No access
+to the shared version store is needed.
+
+1. Workspace read lock, for sanity checks
+1. Workspace *write lock*, for updating the node to reflect the checked
+out state
+1. # Version store read lock, for checking references
+
+The nested lock above is discussed in the section on the save operation.
+
+<a name="Concurrencycontrol-Restore"></a>
+### Restore
+
+The various Node.restore() and Workspace.restore() methods all end up
+calling NodeImpl.internalRestore() that copies contents of the selected
+version back to the workspace. Finally the changes are persisted with a
+ItempImpl.save() call.
+
+1. Multiple non-overlapping instances of:
+1. # Versioning read lock, for copying content back to the workspace
+1. # Workspace read lock, for comparing the current state with the
+version being restored
+1. Workspace *write lock*, for persisting the changes
+1. # Version store read lock, for checking references
+1. # Version store *write lock*, for persisting updated back-references
+
+The nested locks above are discussed in the section on the save operation.
+
+<a name="Concurrencycontrol-Transactioncommit"></a>
+### Transaction commit
+
+!deadlock.jpg|align=right! As discussed in the architecture section above,
+a transaction context overrides all the other write operations in favor of
+the two-phase commit driven by the transaction manager. The Jackrabbit part
+of a potentially distributed transaction is coordinated by the
+XASessionImpl class that causes the following locking behavior:
+
+1. Versioning *write lock*, for the entire commit
+1. # Version store *write lock*, for persisting modified version
+histories
+1. ## Workspace *write lock*, for persisting modified content
+
+The curious ordering of the locks is caused by the way the prepare and
+commit parts of the different transaction components are nested. This
+nesting of the workspace lock within the version store lock is a bit
+troublesome in comparison with the nesting in read operations and
+non-transactional writes where the order of the locks is reverse. The
+nesting order here can not be easily changed as any new versions and
+version histories need to be persisted before workspace content that refers
+to them. Possible solutions could be either to disable or redesign the
+reference checks done in a transactional context, or to relax transaction
+semantics by persisting the version history changes already in the prepare
+phase in which case the version store lock wouldn't need to cover the
+workspace lock. However, even before this issue is fixed, the impact is
+quite limited and can easily be worked around by typical clients.
+
+In read operations the version store read lock is only acquired after the
+workspace lock if reading content in /jcr:system/jcr:versionStorage.
+Clients that never looks at the /jcr:system/jcr:versionStorage tree and
+uses the JCR API methods like getVersionHistory() to access version
+information will not trigger the potential deadlock case.
+
+Write operations can only cause a deadlock when both transactional and
+non-transactional writes are performed concurrently against the same
+repository. A repository that is consistently accessed either
+transactionally or non-transactionally will not trigger this deadlock. Note
+that this restriction is workspace-specific, i.e. one workspace can safely
+be written to transactionally even if another workspace is concurrently
+written to non-transactionally.
+
+<a name="Concurrencycontrol-Summaryandfuturework"></a>
+## Summary and future work
+
+This review shows that while the internal locking behaviour in Jackrabbit
+is still far from simple, there aren't any major deadlock scenarios
+remaining. The two issues identified in the review can be easily avoided by
+following these two rules:
+
+ * Use the JCR versioning API instead of the
+/jcr:system/jcr:versionStorage tree to access version information
+ * Don't mix concurrent transactional and non-transactional writes to a
+single workspace
+
+The transaction commit subsection above outlines some possible solutions to
+make even these workarounds unnecessary.
+
+The following other potential improvements were identified during the code
+review:
+
+ * Storing the version history back-references in the workspaces that
+contain the references would simplify a lot of code and remove a major
+source of interaction between the workspace and version store when updating
+content. The downside of this change is that removing versions and version
+histories would be much more difficult as all workspaces would need to be
+checked for potential references.
+ * The current design contains lots of cases where read locks are
+acquired and released multiple times in sequence. This is often caused by
+the need to check the transient space when reading something from the
+repository. It might be useful to extend the workspace read lock to cover
+also all the transient spaces even when the transient spaces would still be
+session-specific.
+ * Adopting a single global repository lock for all per-repository
+components would simplify lots of code at the expense of some performance.
+
Propchange: jackrabbit/site/trunk/content/concurrency-control.mdtext
------------------------------------------------------------------------------
svn:eol-style = native
Added: jackrabbit/site/trunk/content/continuous-integration.cwiki
URL: http://svn.apache.org/viewvc/jackrabbit/site/trunk/content/continuous-integration.cwiki?rev=1229679&view=auto
==============================================================================
--- jackrabbit/site/trunk/content/continuous-integration.cwiki (added)
+++ jackrabbit/site/trunk/content/continuous-integration.cwiki Tue Jan 10 18:50:59 2012
@@ -0,0 +1,7 @@
+Apache Jackrabbit uses [Hudson|https://hudson.dev.java.net/] for continuous integration builds. The Jackrabbit builds are a part of the [Hudson zone|http://hudson.zones.apache.org/hudson/] in the Apache infrastructure. See the [Hudson wiki page|http://wiki.apache.org/general/Hudson] for more information about the Hudson installation at Apache. The wiki page also contains instructions on how to get an account if you're a member of the [Jackrabbit Team] and want to modify the continuous integration settings.
+
+h2. Build targets and schedule
+
+See the [Jackrabbit page|http://hudson.zones.apache.org/hudson/view/Jackrabbit/] on the Hudson server for the list of configured Jackrabbit builds and their current status.
+
+The builds are configured to hourly check the Subversion server for updates and to run builds whenever there are changes. Build and test errors are reported on the dev@ mailing list.
\ No newline at end of file
Propchange: jackrabbit/site/trunk/content/continuous-integration.cwiki
------------------------------------------------------------------------------
svn:eol-style = native
Added: jackrabbit/site/trunk/content/continuous-integration.mdtext
URL: http://svn.apache.org/viewvc/jackrabbit/site/trunk/content/continuous-integration.mdtext?rev=1229679&view=auto
==============================================================================
--- jackrabbit/site/trunk/content/continuous-integration.mdtext (added)
+++ jackrabbit/site/trunk/content/continuous-integration.mdtext Tue Jan 10 18:50:59 2012
@@ -0,0 +1,19 @@
+Title: Continuous Integration
+Apache Jackrabbit uses [Hudson](https://hudson.dev.java.net/)
+ for continuous integration builds. The Jackrabbit builds are a part of the [Hudson zone|http://hudson.zones.apache.org/hudson/]
+ in the Apache infrastructure. See the [Hudson wiki page|http://wiki.apache.org/general/Hudson]
+ for more information about the Hudson installation at Apache. The wiki
+page also contains instructions on how to get an account if you're a member
+of the [Jackrabbit Team]
+ and want to modify the continuous integration settings.
+
+<a name="ContinuousIntegration-Buildtargetsandschedule"></a>
+## Build targets and schedule
+
+See the [Jackrabbit page](http://hudson.zones.apache.org/hudson/view/Jackrabbit/)
+ on the Hudson server for the list of configured Jackrabbit builds and
+their current status.
+
+The builds are configured to hourly check the Subversion server for updates
+and to run builds whenever there are changes. Build and test errors are
+reported on the dev@ mailing list.
Propchange: jackrabbit/site/trunk/content/continuous-integration.mdtext
------------------------------------------------------------------------------
svn:eol-style = native
Added: jackrabbit/site/trunk/content/creating-releases.cwiki
URL: http://svn.apache.org/viewvc/jackrabbit/site/trunk/content/creating-releases.cwiki?rev=1229679&view=auto
==============================================================================
--- jackrabbit/site/trunk/content/creating-releases.cwiki (added)
+++ jackrabbit/site/trunk/content/creating-releases.cwiki Tue Jan 10 18:50:59 2012
@@ -0,0 +1,83 @@
+This is a how to document for creating Apache Jackrabbit releases. It documents the current release process and needs to be updated as we move forward.
+
+h2. Release planning
+
+Jackrabbit releases are created based on user demand and the availability of fixes and other requested changes. Any committer can declare their plan to cut a release by sending a "Apache Jackrabbit x.y.z release plan" message to the dev@ list. The plan should refer to Jira for the list of fixes to be included in the release and give a rough estimate of the release schedule. It's OK to revise the plan if needed.
+
+If you're not a committer, you can send a message to the mailing list asking for a new release to be made. Including the list of specific fixes you need and a short rationale of why you need the release.
+
+h2. Prerequisites for release managers
+
+You need to be a Jackrabbit committer to prepare and perform a release, but anyone is welcome to help test the release candidates and comment on the release plans.
+
+You should have a code signing key that is included in the Jackrabbit KEYS file. See Appendix A at the end of this page for more details.
+
+You also need to tell Maven your Subversion credentials needed for deploying artifacts to the Nexus server at https://repository.apache.org/. See Appendix B for the required settings.
+
+h2. Release management tasks
+
+# Make sure that an appropriate version for the release is entered in Jira and that all the related issues have been resolved.
+* Create a {{RELEASE-NOTES.txt}} file in the root folder of the project to be released. If such a file already exists, update it for the release. When done, commit the file. See previous release notes for examples of what to include. The release note report in Jira is a useful source of required information.
+# Build and deploy the release artifacts with Maven. See below for the exact steps.
+# Close the staged repository on repository.apache.org.
+# Start the vote thread, wait 72 hours. See the vote template generated by the Maven build.
+# If the vote fails (easy case first) remove the tag from svn and drop the staged repository - done
+# If the vote is successful, copy the release archives to the dist directory on www.apache.org, delete the old release there (its automatically archived), and promote the staged repository for synchronization to Maven central.
+# Update the Jackrabbit web site to point to the new release.
+# Send the release announcement once the web site and download mirrors have been synced.
+# Mark the version as released in Jira and close all related issues.
+
+h2. Steps to build the release artifacts
+
+The release is built using the Maven release plugin. See the [Releasing a Maven project|http://maven.apache.org/developers/release/releasing.html] guide for more details.
+
+# Execute {{mvn release:prepare}}. This will update the POM files and tag the release in svn.
+# Execute {{mvn release:perform}}. This will build the tagged release and deploy the artifacts to a staging repository on repository.apache.org. The non-Maven release artifacts are automatically deployed to your home directory on people.apache.org.
+
+h2. Related Links
+
+* http://www.apache.org/dev/release.html
+* http://www.apache.org/dev/release-signing.html
+* http://wiki.apache.org/incubator/SigningReleases
+* http://www.apache.org/dev/repository-faq.html
+
+h2. Appendix A: Create and add your key to the Jackrabbit KEYS file
+
+Follow these instructions to generate your code signing key and to add it to the Jackrabbit KEYS file.
+
+# [Generate a code signing key|http://www.apache.org/dev/release-signing.html#generate] using your @apache.org address as the email and "CODE SIGNING KEY" as the comment.
+# The Jackrabbit KEYS file is managed in https://svn.apache.org/repos/asf/jackrabbit/dist/KEYS. To modify the file, first checkout the dist directory:
+{code:none}
+svn checkout https://svn.apache.org/repos/asf/jackrabbit/dist
+{code}
+# See the beginning of the KEYS file for instructions on how to append your key to the file.
+# Once you've committed the changes, update the KEYS file on {{people.apache.org}}:
+{code:none}
+umask 002; svn update /www/www.apache.org/dist/jackrabbit
+{code}
+# You are *DONE*, but to see the changes on http://www.apache.org/dist/jackrabbit/KEYS you must wait 2 hours
+
+You should get your key [linked to the Apache web of trust|http://www.apache.org/dev/release-signing.html#apache-wot]. Once other people have signed your key, you can update the KEYS file with the signatures you've received.
+
+h2. Appendix B: Maven settings
+
+{code:xml}
+<settings>
+...
+ <servers>
+ <!-- To deploy a Jackrabbit snapshot -->
+ <server>
+ <id>apache.snapshots.https</id>
+ <username> <!-- YOUR APACHE SVN USERNAME --> </username>
+ <password> <!-- YOUR APACHE SVN PASSWORD --> </password>
+ </server>
+ <!-- To stage a Jackrabbit release -->
+ <server>
+ <id>apache.releases.https</id>
+ <username> <!-- YOUR APACHE SVN USERNAME --> </username>
+ <password> <!-- YOUR APACHE SVN PASSWORD --> </password>
+ </server>
+ ...
+ </servers>
+</settings>
+{code}
\ No newline at end of file
Propchange: jackrabbit/site/trunk/content/creating-releases.cwiki
------------------------------------------------------------------------------
svn:eol-style = native
Added: jackrabbit/site/trunk/content/creating-releases.mdtext
URL: http://svn.apache.org/viewvc/jackrabbit/site/trunk/content/creating-releases.mdtext?rev=1229679&view=auto
==============================================================================
--- jackrabbit/site/trunk/content/creating-releases.mdtext (added)
+++ jackrabbit/site/trunk/content/creating-releases.mdtext Tue Jan 10 18:50:59 2012
@@ -0,0 +1,132 @@
+Title: Creating Releases
+This is a how to document for creating Apache Jackrabbit releases. It
+documents the current release process and needs to be updated as we move
+forward.
+
+<a name="CreatingReleases-Releaseplanning"></a>
+## Release planning
+
+Jackrabbit releases are created based on user demand and the availability
+of fixes and other requested changes. Any committer can declare their plan
+to cut a release by sending a "Apache Jackrabbit x.y.z release plan"
+message to the dev@ list. The plan should refer to Jira for the list of
+fixes to be included in the release and give a rough estimate of the
+release schedule. It's OK to revise the plan if needed.
+
+If you're not a committer, you can send a message to the mailing list
+asking for a new release to be made. Including the list of specific fixes
+you need and a short rationale of why you need the release.
+
+<a name="CreatingReleases-Prerequisitesforreleasemanagers"></a>
+## Prerequisites for release managers
+
+You need to be a Jackrabbit committer to prepare and perform a release, but
+anyone is welcome to help test the release candidates and comment on the
+release plans.
+
+You should have a code signing key that is included in the Jackrabbit KEYS
+file. See Appendix A at the end of this page for more details.
+
+You also need to tell Maven your Subversion credentials needed for
+deploying artifacts to the Nexus server at https://repository.apache.org/.
+See Appendix B for the required settings.
+
+<a name="CreatingReleases-Releasemanagementtasks"></a>
+## Release management tasks
+
+1. Make sure that an appropriate version for the release is entered in Jira
+and that all the related issues have been resolved.
+* Create a *RELEASE-NOTES.txt* file in the root folder of the project to
+be released. If such a file already exists, update it for the release. When
+done, commit the file. See previous release notes for examples of what to
+include. The release note report in Jira is a useful source of required
+information.
+1. Build and deploy the release artifacts with Maven. See below for the
+exact steps.
+1. Close the staged repository on repository.apache.org.
+1. Start the vote thread, wait 72 hours. See the vote template generated by
+the Maven build.
+1. If the vote fails (easy case first) remove the tag from svn and drop the
+staged repository - done
+1. If the vote is successful, copy the release archives to the dist
+directory on www.apache.org, delete the old release there (its
+automatically archived), and promote the staged repository for
+synchronization to Maven central.
+1. Update the Jackrabbit web site to point to the new release.
+1. Send the release announcement once the web site and download mirrors have
+been synced.
+1. Mark the version as released in Jira and close all related issues.
+
+<a name="CreatingReleases-Stepstobuildthereleaseartifacts"></a>
+## Steps to build the release artifacts
+
+The release is built using the Maven release plugin. See the [Releasing a Maven project](http://maven.apache.org/developers/release/releasing.html)
+ guide for more details.
+
+1. Execute *mvn release:prepare*. This will update the POM files and tag
+the release in svn.
+1. Execute *mvn release:perform*. This will build the tagged release and
+deploy the artifacts to a staging repository on repository.apache.org. The
+non-Maven release artifacts are automatically deployed to your home
+directory on people.apache.org.
+
+<a name="CreatingReleases-RelatedLinks"></a>
+## Related Links
+
+* http://www.apache.org/dev/release.html
+* http://www.apache.org/dev/release-signing.html
+* http://wiki.apache.org/incubator/SigningReleases
+* http://www.apache.org/dev/repository-faq.html
+
+<a name="CreatingReleases-AppendixA:CreateandaddyourkeytotheJackrabbitKEYSfile"></a>
+## Appendix A: Create and add your key to the Jackrabbit KEYS file
+
+Follow these instructions to generate your code signing key and to add it
+to the Jackrabbit KEYS file.
+
+1. [Generate a code signing key](http://www.apache.org/dev/release-signing.html#generate)
+ using your @apache.org address as the email and "CODE SIGNING KEY" as the
+comment.
+1. The Jackrabbit KEYS file is managed in
+https://svn.apache.org/repos/asf/jackrabbit/dist/KEYS. To modify the file,
+first checkout the dist directory:
+{code:none}
+svn checkout https://svn.apache.org/repos/asf/jackrabbit/dist
+
+ # See the beginning of the KEYS file for instructions on how to append your
+key to the file.
+ # Once you've committed the changes, update the KEYS file on
+{{people.apache.org}}:
+ {code:none}
+ umask 002; svn update /www/www.apache.org/dist/jackrabbit
+
+1. You are *DONE*, but to see the changes on
+http://www.apache.org/dist/jackrabbit/KEYS you must wait 2 hours
+
+You should get your key [linked to the Apache web of trust](http://www.apache.org/dev/release-signing.html#apache-wot)
+. Once other people have signed your key, you can update the KEYS file with
+the signatures you've received.
+
+<a name="CreatingReleases-AppendixB:Mavensettings"></a>
+## Appendix B: Maven settings
+
+
+ <settings>
+ ...
+ <servers>
+ <!-- To deploy a Jackrabbit snapshot -->
+ <server>
+ <id>apache.snapshots.https</id>
+ <username> <!-- YOUR APACHE SVN USERNAME --> </username>
+ <password> <!-- YOUR APACHE SVN PASSWORD --> </password>
+ </server>
+ <!-- To stage a Jackrabbit release -->
+ <server>
+ <id>apache.releases.https</id>
+ <username> <!-- YOUR APACHE SVN USERNAME --> </username>
+ <password> <!-- YOUR APACHE SVN PASSWORD --> </password>
+ </server>
+ ...
+ </servers>
+ </settings>
+
Propchange: jackrabbit/site/trunk/content/creating-releases.mdtext
------------------------------------------------------------------------------
svn:eol-style = native
Added: jackrabbit/site/trunk/content/deployment-models.cwiki
URL: http://svn.apache.org/viewvc/jackrabbit/site/trunk/content/deployment-models.cwiki?rev=1229679&view=auto
==============================================================================
--- jackrabbit/site/trunk/content/deployment-models.cwiki (added)
+++ jackrabbit/site/trunk/content/deployment-models.cwiki Tue Jan 10 18:50:59 2012
@@ -0,0 +1,58 @@
+JSR-170 explicitly allows for numerous different deployment models, meaning that it is entirely up to the repository implementation to suggest certain models.
+
+Jackrabbit is built to support a variety of different deployment models, some of the possibilities on how to deploy Jackrabbit will be outlined here.
+
+See also the following HOWTO documents for setting up and using the different deployment models:
+
+* [JCR client application HOWTO]
+* Model 1: [Application Bundle HOWTO]
+* Model 2: [Shared J2EE Resource HOWTO]
+* Model 3: [Repository Server HOWTO]
+
+h2. Model 1: The (Web-) Application Bundle
+
+For many applications, usually applications that run in a closed context without interacting with other applications or data sources, it might be desirable to bundle a content repository with the application itself.
+
+Jackrabbit is built for this lightweight model and allows obviously through the abstraction provided by JSR-170 to move at any point in time to a different deployment model in case this should be desirable for the context that the application runs in.
+
+This makes Jackrabbit ideal to be packaged as a lightweight out-of-the-box content repository that allows an application vendor to make sure that there are no dependencies to a pre-installed content repository.
+
+The instance of Jackrabbit that is package with the application is running in-proc inside the same JVM and cannot be accessed by any other application.
+
+This deployment model is particularly lightweight and does not require a network layer.
+
+The individual repository instances are started and stopped with their containing applications, which means that the application is not only connecting to the repository but is also in charge of starting and stopping the repository.
+
+As an example of this deployment model we assume a WebApplication packaged into a .war file which is deployed into a WebContainer, which not only contains the application but also the actual content repository.
+
+{center}!deploy-1.png!{center}
+
+Application1 and Application2 both contain their own instances of a Content Repository distributed as a part of their .war file and therefore loaded with the web application's class loader which makes it invisible to other applications.
+
+This deployment model of course also works for any stand-alone application and not just for web applications.
+
+h2. Model 2: Shared J2EE Resource
+
+A second way to deploy a repository is to make it visible as a resource to all the web applications that are running inside a Servlet Container by registering the Repository as a Resource Adapter to the Application Server.
+
+Similar to the first deployment model this deployment model does also not require a network layer and therefore would be considered in-proc and is running inside the same JVM.
+
+The repository is started and stopped with the Application Server but is visible to all the applications to connect to.
+
+{center}!deploy-2.png!{center}
+
+This setup also allows to take advantage of the XA facilities of the Application Server and could use the application servers single sign-on mechanisms that are provided as part of the J2EE framework.
+
+h2. Model 3: The Repository Server
+
+In enterprise environments the client/server deployment model is widely used for relational databases. While with relational databases this is probably the only deployment model that is supported by most RDBMS vendors for repositories, in particular for Jackrabbit, this is only on various options.
+
+The client/server deployment model will certainly be very popular in environments that where it is desirable to physically separate the content repository (or data) layer from the application or presentation layer, so the content repository can be used from many different applications, physically and can be scaled individually.
+
+{center}!deploy-3.png!{center}
+
+This deployment model assumes that there is a network layer between the content repository server and the respective content repository client.
+
+While the applications communicate through the JSR-170 API with the content repository client. The content repository client then communicates through any form of transport protocol with the stand-alone content repository server.
+
+The transport protocol between the client and the server is subject to implementation and not mandated by JSR-170. Popular choices might include RMI over JRMP or IIOP or WebDAV and its extensions.
Propchange: jackrabbit/site/trunk/content/deployment-models.cwiki
------------------------------------------------------------------------------
svn:eol-style = native
Added: jackrabbit/site/trunk/content/deployment-models.mdtext
URL: http://svn.apache.org/viewvc/jackrabbit/site/trunk/content/deployment-models.mdtext?rev=1229679&view=auto
==============================================================================
--- jackrabbit/site/trunk/content/deployment-models.mdtext (added)
+++ jackrabbit/site/trunk/content/deployment-models.mdtext Tue Jan 10 18:50:59 2012
@@ -0,0 +1,107 @@
+Title: Deployment Models
+JSR-170 explicitly allows for numerous different deployment models, meaning
+that it is entirely up to the repository implementation to suggest certain
+models.
+
+Jackrabbit is built to support a variety of different deployment models,
+some of the possibilities on how to deploy Jackrabbit will be outlined
+here.
+
+See also the following HOWTO documents for setting up and using the
+different deployment models:
+
+* [JCR client application HOWTO](jcr-client-application-howto.html)
+* Model 1: [Application Bundle HOWTO](application-bundle-howto.html)
+* Model 2: [Shared J2EE Resource HOWTO](shared-j2ee-resource-howto.html)
+* Model 3: [Repository Server HOWTO](repository-server-howto.html)
+
+<a name="DeploymentModels-Model1:The(Web-)ApplicationBundle"></a>
+## Model 1: The (Web-) Application Bundle
+
+For many applications, usually applications that run in a closed context
+without interacting with other applications or data sources, it might be
+desirable to bundle a content repository with the application itself.
+
+Jackrabbit is built for this lightweight model and allows obviously through
+the abstraction provided by JSR-170 to move at any point in time to a
+different deployment model in case this should be desirable for the context
+that the application runs in.
+
+This makes Jackrabbit ideal to be packaged as a lightweight out-of-the-box
+content repository that allows an application vendor to make sure that
+there are no dependencies to a pre-installed content repository.
+
+The instance of Jackrabbit that is package with the application is running
+in-proc inside the same JVM and cannot be accessed by any other
+application.
+
+This deployment model is particularly lightweight and does not require a
+network layer.
+
+The individual repository instances are started and stopped with their
+containing applications, which means that the application is not only
+connecting to the repository but is also in charge of starting and stopping
+the repository.
+
+As an example of this deployment model we assume a WebApplication packaged
+into a .war file which is deployed into a WebContainer, which not only
+contains the application but also the actual content repository.
+
+{center}!deploy-1.png!{center}
+
+Application1 and Application2 both contain their own instances of a Content
+Repository distributed as a part of their .war file and therefore loaded
+with the web application's class loader which makes it invisible to other
+applications.
+
+This deployment model of course also works for any stand-alone application
+and not just for web applications.
+
+<a name="DeploymentModels-Model2:SharedJ2EEResource"></a>
+## Model 2: Shared J2EE Resource
+
+A second way to deploy a repository is to make it visible as a resource to
+all the web applications that are running inside a Servlet Container by
+registering the Repository as a Resource Adapter to the Application Server.
+
+Similar to the first deployment model this deployment model does also not
+require a network layer and therefore would be considered in-proc and is
+running inside the same JVM.
+
+The repository is started and stopped with the Application Server but is
+visible to all the applications to connect to.
+
+{center}!deploy-2.png!{center}
+
+This setup also allows to take advantage of the XA facilities of the
+Application Server and could use the application servers single sign-on
+mechanisms that are provided as part of the J2EE framework.
+
+<a name="DeploymentModels-Model3:TheRepositoryServer"></a>
+## Model 3: The Repository Server
+
+In enterprise environments the client/server deployment model is widely
+used for relational databases. While with relational databases this is
+probably the only deployment model that is supported by most RDBMS vendors
+for repositories, in particular for Jackrabbit, this is only on various
+options.
+
+The client/server deployment model will certainly be very popular in
+environments that where it is desirable to physically separate the content
+repository (or data) layer from the application or presentation layer, so
+the content repository can be used from many different applications,
+physically and can be scaled individually.
+
+{center}!deploy-3.png!{center}
+
+This deployment model assumes that there is a network layer between the
+content repository server and the respective content repository client.
+
+While the applications communicate through the JSR-170 API with the content
+repository client. The content repository client then communicates through
+any form of transport protocol with the stand-alone content repository
+server.
+
+The transport protocol between the client and the server is subject to
+implementation and not mandated by JSR-170. Popular choices might include
+RMI over JRMP or IIOP or WebDAV and its extensions.
Propchange: jackrabbit/site/trunk/content/deployment-models.mdtext
------------------------------------------------------------------------------
svn:eol-style = native
Added: jackrabbit/site/trunk/content/documentation.cwiki
URL: http://svn.apache.org/viewvc/jackrabbit/site/trunk/content/documentation.cwiki?rev=1229679&view=auto
==============================================================================
--- jackrabbit/site/trunk/content/documentation.cwiki (added)
+++ jackrabbit/site/trunk/content/documentation.cwiki Tue Jan 10 18:50:59 2012
@@ -0,0 +1,9 @@
+* [Getting Started with Apache Jackrabbit]
+* [Jackrabbit Components]
+* [Building Jackrabbit]
+* [First Hops]
+* [JCR & API]
+* [Jackrabbit Architecture]
+* [Deployment Models]
+* [Jackrabbit Configuration]
+* [Node Types]
\ No newline at end of file
Propchange: jackrabbit/site/trunk/content/documentation.cwiki
------------------------------------------------------------------------------
svn:eol-style = native
Added: jackrabbit/site/trunk/content/documentation.mdtext
URL: http://svn.apache.org/viewvc/jackrabbit/site/trunk/content/documentation.mdtext?rev=1229679&view=auto
==============================================================================
--- jackrabbit/site/trunk/content/documentation.mdtext (added)
+++ jackrabbit/site/trunk/content/documentation.mdtext Tue Jan 10 18:50:59 2012
@@ -0,0 +1,10 @@
+Title: Documentation
+* [Getting Started with Apache Jackrabbit](getting-started-with-apache-jackrabbit.html)
+* [Jackrabbit Components](jackrabbit-components.html)
+* [Building Jackrabbit](building-jackrabbit.html)
+* [First Hops](first-hops.html)
+* [JCR & API](jcr-&-api.html)
+* [Jackrabbit Architecture](jackrabbit-architecture.html)
+* [Deployment Models](deployment-models.html)
+* [Jackrabbit Configuration](jackrabbit-configuration.html)
+* [Node Types](node-types.html)
Propchange: jackrabbit/site/trunk/content/documentation.mdtext
------------------------------------------------------------------------------
svn:eol-style = native
Added: jackrabbit/site/trunk/content/downloads.cwiki
URL: http://svn.apache.org/viewvc/jackrabbit/site/trunk/content/downloads.cwiki?rev=1229679&view=auto
==============================================================================
--- jackrabbit/site/trunk/content/downloads.cwiki (added)
+++ jackrabbit/site/trunk/content/downloads.cwiki Tue Jan 10 18:50:59 2012
@@ -0,0 +1,152 @@
+Use the links below to download Apache Jackrabbit releases from one of our mirrors. You should [verify the integrity|#verify] of the files using the signatures and checksums available from this page.
+
+* Latest unstable release: [Apache Jackrabbit 2.3.6|#v23]
+* Latest stable release: [Apache Jackrabbit 2.2.10|#v22]
+* Maintenance releases: [Apache Jackrabbit 2.1.6|#v21], [Apache Jackrabbit 2.0.5|#v20]
+* End of life release: [Apache Jackrabbit 1.6.5|#v16]
+* [Release Archive|#archive]
+
+Apache Jackrabbit releases are available under the [Apache License, Version 2.0|http://www.apache.org/licenses/LICENSE-2.0]. See the {{NOTICE.txt}} file contained in each release artifact for applicable copyright attribution notices. Some Jackrabbit components contain external code with licenses that meet [Apache licensing policies|http://www.apache.org/legal/resolved.html]. See the {{LICENSE.txt}} file contained in each release artifact for applicable licenses.
+
+h2. {anchor:v23}Apache Jackrabbit 2.3.6
+
+Apache Jackrabbit 2.3 is an unstable series of releases cut directly from Jackrabbit trunk, with a focus on new features and other improvements. For production use we recommend the [latest stable 2.2 release|#v22].
+
+See the [full release notes|http://www.apache.org/dist/jackrabbit/2.3.6/RELEASE-NOTES.txt] for more details.
+
+* [jackrabbit-2.3.6-src.zip|http://www.apache.org/dyn/closer.cgi/jackrabbit/2.3.6/jackrabbit-2.3.6-src.zip] (512B, source zip, [PGP signature|http://www.apache.org/dist/jackrabbit/2.3.6/jackrabbit-2.3.6-src.zip.asc])
+ SHA1 checksum: {{e6016eb8165b19db3e5d86cd8b73be9f5fa99f35}}
+ MD5 checksum: {{676ee9b6fa704faf18f6dbb8a40aa3e6}}
+
+* [jackrabbit-standalone-2.3.6.jar|http://www.apache.org/dyn/closer.cgi/jackrabbit/2.3.6/jackrabbit-standalone-2.3.6.jar] (43M, standalone server, [PGP signature|http://www.apache.org/dist/jackrabbit/2.3.6/jackrabbit-standalone-2.3.6.jar.asc])
+ SHA1 checksum: {{0876215d99fe8aabd6a3e06e0b1c9d60a0c3b547}}
+ MD5 checksum: {{48d3533b60fbf3d2999a84404be37819}}
+
+* [jackrabbit-webapp-2.3.6.war|http://www.apache.org/dyn/closer.cgi/jackrabbit/2.3.6/jackrabbit-webapp-2.3.6.war] (24M, web application, [PGP signature|http://www.apache.org/dist/jackrabbit/2.3.6/jackrabbit-webapp-2.3.6.war.asc])
+ SHA1 checksum: {{d86aaa707d280052c31a7c59cb1d00402cdd2c86}}
+ MD5 checksum: {{c5b239b9932588539791ec41d3888e53}}
+
+* [jackrabbit-jca-2.3.6.rar|http://www.apache.org/dyn/closer.cgi/jackrabbit/2.3.6/jackrabbit-jca-2.3.6.rar] (512B, JCA resource adapter, [PGP signature|http://www.apache.org/dist/jackrabbit/2.3.6/jackrabbit-jca-2.3.6.rar.asc])
+ SHA1 checksum: {{415f894e1b4117da6deb9829e06ab02f9ef7dcfd}}
+ MD5 checksum: {{9dc6fbad2256c6fb9043b4714121c48b}}
+
+h2. {anchor:v22}Apache Jackrabbit 2.2.10
+
+Apache Jackrabbit 2.2.10 is patch release that contains fixes and improvements over previous 2.2.x releases. This release is fully compatible with earlier 2.x.x releases.
+
+See the [full release notes|http://www.apache.org/dist/jackrabbit/2.2.10/RELEASE-NOTES.txt] for more details.
+
+* [jackrabbit-2.2.10-src.zip|http://www.apache.org/dyn/closer.cgi/jackrabbit/2.2.10/jackrabbit-2.2.10-src.zip] (10M, source zip, [PGP signature|http://www.apache.org/dist/jackrabbit/2.2.10/jackrabbit-2.2.10-src.zip.asc])
+ SHA1 checksum: {{d0e80e02f099e15cf91785ec25dc0c2128152930}}
+ MD5 checksum: {{89008240f50e2b3819b00b429d45247e}}
+
+* [jackrabbit-standalone-2.2.10.jar|http://www.apache.org/dyn/closer.cgi/jackrabbit/2.2.10/jackrabbit-standalone-2.2.10.jar] (33M, standalone server, [PGP signature|http://www.apache.org/dist/jackrabbit/2.2.10/jackrabbit-standalone-2.2.10.jar.asc])
+ SHA1 checksum: {{af77d3d5db6d52471d0e4b4662a1080ce42c26ec}}
+ MD5 checksum: {{bcc017ed51227bb208da5f335d3e157c}}
+
+* [jackrabbit-webapp-2.2.10.war|http://www.apache.org/dyn/closer.cgi/jackrabbit/2.2.10/jackrabbit-webapp-2.2.10.war] (20M, web application, [PGP signature|http://www.apache.org/dist/jackrabbit/2.2.10/jackrabbit-webapp-2.2.10.war.asc])
+ SHA1 checksum: {{5c2209489f2482042d712eefa716d345b6ed679e}}
+ MD5 checksum: {{7cd56f485d0d73fefac5fe06173ab3e6}}
+
+* [jackrabbit-jca-2.2.10.rar|http://www.apache.org/dyn/closer.cgi/jackrabbit/2.2.10/jackrabbit-jca-2.2.10.rar] (25M, JCA resource adapter, [PGP signature|http://www.apache.org/dist/jackrabbit/2.2.10/jackrabbit-jca-2.2.10.rar.asc])
+ SHA1 checksum: {{42058acb2eeb49f71e5be8135da07a7809647258}}
+ MD5 checksum: {{c32054a0dceb78de0be1f11b9bf0c314}}
+
+h2. {anchor:v21}Apache Jackrabbit 2.1.6
+
+Apache Jackrabbit 2.1.6 is a bug fix release that fixes issues reported against previous releases. This release is fully compatible with the earlier 2.1.x releases.
+
+See the [full release notes|http://www.apache.org/dist/jackrabbit/2.1.6/RELEASE-NOTES.txt] for more details.
+
+* [jackrabbit-2.1.6-src.zip|http://www.apache.org/dyn/closer.cgi/jackrabbit/2.1.6/jackrabbit-2.1.6-src.zip] (6.5M, source zip, [PGP signature|http://www.apache.org/dist/jackrabbit/2.1.6/jackrabbit-2.1.6-src.zip.asc])
+ SHA1 checksum: {{dc8bc82bca06292a3dd21ba3859da4c1a911daac}}
+ MD5 checksum: {{0f8b5224454937d3a2c3ed9b12a50e32}}
+
+* [jackrabbit-standalone-2.1.6.jar|http://www.apache.org/dyn/closer.cgi/jackrabbit/2.1.6/jackrabbit-standalone-2.1.6.jar] (32M, standalone server, [PGP signature|http://www.apache.org/dist/jackrabbit/2.1.6/jackrabbit-standalone-2.1.6.jar.asc])
+ SHA1 checksum: {{fdef08602dbe3ee83a31febbbb1ca30e0d82c632}}
+ MD5 checksum: {{ca2f261c10d8313938492afa45fc0317}}
+
+* [jackrabbit-webapp-2.1.6.war|http://www.apache.org/dyn/closer.cgi/jackrabbit/2.1.6/jackrabbit-webapp-2.1.6.war] (22M, web application, [PGP signature|http://www.apache.org/dist/jackrabbit/2.1.6/jackrabbit-webapp-2.1.6.war.asc])
+ SHA1 checksum: {{c60039fc89a33fda2784872be6f83652213c7664}}
+ MD5 checksum: {{7f7569eaafa1a879b8cd62eca4ddb3c8}}
+
+* [jackrabbit-jca-2.1.6.rar|http://www.apache.org/dyn/closer.cgi/jackrabbit/2.1.6/jackrabbit-jca-2.1.6.rar] (20M, JCA resource adapter, [PGP signature|http://www.apache.org/dist/jackrabbit/2.1.6/jackrabbit-jca-2.1.6.rar.asc])
+ SHA1 checksum: {{cc6849e837d8f2a6ed217de706c56c0e5f7028b1}}
+ MD5 checksum: {{a7037c012e35c43675394db127b5f0c5}}
+
+h2. {anchor:v20}Apache Jackrabbit 2.0.5
+
+Apache Jackrabbit 2.0.5 is a bug fix release that fixes issues reported against previous releases. This release is fully compatible with the earlier 2.0.x releases.
+
+See the [full release notes|http://www.apache.org/dist/jackrabbit/2.0.5/RELEASE-NOTES.txt] for more details.
+
+* [jackrabbit-2.0.5-src.zip|http://www.apache.org/dyn/closer.cgi/jackrabbit/2.0.5/jackrabbit-2.0.5-src.zip] (6.2M, source zip, [PGP signature|http://www.apache.org/dist/jackrabbit/2.0.5/jackrabbit-2.0.5-src.zip.asc])
+ SHA1 checksum: {{e1b29e484ed2dde5ec1efc395e4035c44d6ea61f}}
+ MD5 checksum: {{5463a14a95fe18a8da7a6e4861751d4a}}
+
+* [jackrabbit-standalone-2.0.5.jar|http://www.apache.org/dyn/closer.cgi/jackrabbit/2.0.5/jackrabbit-standalone-2.0.5.jar] (41M, standalone server, [PGP signature|http://www.apache.org/dist/jackrabbit/2.0.5/jackrabbit-standalone-2.0.5.jar.asc])
+ SHA1 checksum: {{8ab7acebbc402f9092128fd4552110f03c0ffb53}}
+ MD5 checksum: {{91cd68164a4f6b738578e9a288ab2bc5}}
+
+* [jackrabbit-webapp-2.0.5.war|http://www.apache.org/dyn/closer.cgi/jackrabbit/2.0.5/jackrabbit-webapp-2.0.5.war] (29M, web application, [PGP signature|http://www.apache.org/dist/jackrabbit/2.0.5/jackrabbit-webapp-2.0.5.war.asc])
+ SHA1 checksum: {{4d70a6bfd0d7b9f18a59803e8f178711d4f9a0cf}}
+ MD5 checksum: {{5c7a93ff714685383bf8a54b5f28e7d5}}
+
+* [jackrabbit-jca-2.0.5.rar|http://www.apache.org/dyn/closer.cgi/jackrabbit/2.0.5/jackrabbit-jca-2.0.5.rar] (26M, JCA resource adapter, [PGP signature|http://www.apache.org/dist/jackrabbit/2.0.5/jackrabbit-jca-2.0.5.rar.asc])
+ SHA1 checksum: {{ea72a4b9e8ea0c0fa5047b976ec8430deff2dc35}}
+ MD5 checksum: {{406252030cc64ca7203b67c671f71953}}
+
+h2. {anchor:v16}Apache Jackrabbit 1.6.5
+
+Apache Jackrabbit 1.6.5 is a bug fix release that fixes issues reported against previous releases. This release is backwards-compatible with the earlier 1.6.x releases, but contains a change in persistence format that makes it impossible to downgrade to releases earlier than 1.6.2 after a repository has been upgraded. A full backup of the repository is recommended before this upgrade.
+
+{note}This patch release marks the end of active maintenance of the Jackrabbit 1.6 branch. All users are encouraged to upgrade to the more recent Jackrabbit 2.x versions.{note}
+
+See the [full release notes|http://www.apache.org/dist/jackrabbit/1.6.5/RELEASE-NOTES.txt] for more details.
+
+* [jackrabbit-1.6.5-src.zip|http://www.apache.org/dyn/closer.cgi/jackrabbit/1.6.5/jackrabbit-1.6.5-src.zip] (5.7M, source zip, [PGP signature|http://www.apache.org/dist/jackrabbit/1.6.5/jackrabbit-1.6.5-src.zip.asc])
+ SHA1 checksum: {{4fa1e032f9b641fbc5c9ff8d6ba76fdb58b539ba}}
+ MD5 checksum: {{c54349f1f00e4d0f95f7e16dd3f5da11}}
+
+* [jackrabbit-standalone-1.6.5.jar|http://www.apache.org/dyn/closer.cgi/jackrabbit/1.6.5/jackrabbit-standalone-1.6.5.jar] (21M, standalone server, [PGP signature|http://www.apache.org/dist/jackrabbit/1.6.5/jackrabbit-standalone-1.6.5.jar.asc])
+ SHA1 checksum: {{a9be78279c3987a7550d91f173b42bba9f801c4c}}
+ MD5 checksum: {{6efcdd934e22b5dd5183638be7202a1f}}
+
+* [jackrabbit-webapp-1.6.5.war|http://www.apache.org/dyn/closer.cgi/jackrabbit/1.6.5/jackrabbit-webapp-1.6.5.war] (14M, web application, [PGP signature|http://www.apache.org/dist/jackrabbit/1.6.5/jackrabbit-webapp-1.6.5.war.asc])
+ SHA1 checksum: {{ea352bce5528c819fec9a534838f1852e4c31bb5}}
+ MD5 checksum: {{642daded0a09e19544b510cd390ce621}}
+
+* [jackrabbit-jca-1.6.5.rar|http://www.apache.org/dyn/closer.cgi/jackrabbit/1.6.5/jackrabbit-jca-1.6.5.rar] (13M, JCA resource adapter, [PGP signature|http://www.apache.org/dist/jackrabbit/1.6.5/jackrabbit-jca-1.6.5.rar.asc])
+ SHA1 checksum: {{3d5934b96f931c21da7bcffdf2c04999396c5d83}}
+ MD5 checksum: {{bb6c29df607ac7a6b117da4fc9aa3683}}
+
+h2. {anchor:archive} Release Archive
+
+Only current recommended releases are available on the main distribution site and its mirrors. Older releases are available from the [archive download site|http://archive.apache.org/dist/jackrabbit/].
+
+h2. {anchor:verify} Verify
+
+It is essential that you verify the integrity of the downloaded files using the PGP signatures or MD5 and SHA1 checksums. Please read [Verifying Apache HTTP Server Releases|http://httpd.apache.org/dev/verification.html] for more information on why you should verify our releases.
+
+The PGP signatures can be verified using PGP or GPG. First download the [KEYS|http://www.apache.org/dist/jackrabbit/KEYS] file as well as the {{.asc}} signature files for the relevant release packages. Make sure you get these files from the [main distribution directory|http://www.apache.org/dist/jackrabbit/], rather than from a mirror. Then verify the signatures using
+
+{code}
+% pgpk -a KEYS
+% pgpv jackrabbit-X.Y.Z-src.zip.asc
+{code}
+
+or
+
+{code}
+% pgp -ka KEYS
+% pgp jackrabbit-X.Y.Z-src.zip.asc
+{code}
+
+or
+
+{code}
+% gpg --import KEYS
+% gpg --verify jackrabbit-X.Y.Z-src.zip.asc
+{code}
+
+Alternatively, you can verify the MD5 or SHA1 checksums on the files. For checking the MD5 checksums, use the program called {{md5}} or {{md5sum}} included in many Unix distributions. The similar program for SHA1 is called {{sha1sum}}. It is also available as part of the [GNU core utilities|http://www.gnu.org/software/coreutils/]. Windows users can get binary md5 programs from [here|http://www.fourmilab.ch/md5/], [here|http://www.pc-tools.net/win32/md5sums/], or [here|http://www.slavasoft.com/fsum/].
\ No newline at end of file
Propchange: jackrabbit/site/trunk/content/downloads.cwiki
------------------------------------------------------------------------------
svn:eol-style = native
Added: jackrabbit/site/trunk/content/downloads.mdtext
URL: http://svn.apache.org/viewvc/jackrabbit/site/trunk/content/downloads.mdtext?rev=1229679&view=auto
==============================================================================
--- jackrabbit/site/trunk/content/downloads.mdtext (added)
+++ jackrabbit/site/trunk/content/downloads.mdtext Tue Jan 10 18:50:59 2012
@@ -0,0 +1,243 @@
+Title: Downloads
+Use the links below to download Apache Jackrabbit releases from one of our
+mirrors. You should [verify the integrity](#verify.html)
+ of the files using the signatures and checksums available from this page.
+
+* Latest unstable release: [Apache Jackrabbit 2.3.6](#v23.html)
+* Latest stable release: [Apache Jackrabbit 2.2.10](#v22.html)
+* Maintenance releases: [Apache Jackrabbit 2.1.6](#v21.html)
+, [Apache Jackrabbit 2.0.5|#v20]
+* End of life release: [Apache Jackrabbit 1.6.5](#v16.html)
+* [Release Archive](#archive.html)
+
+Apache Jackrabbit releases are available under the [Apache License, Version 2.0](http://www.apache.org/licenses/LICENSE-2.0)
+. See the *NOTICE.txt* file contained in each release artifact for
+applicable copyright attribution notices. Some Jackrabbit components
+contain external code with licenses that meet [Apache licensing policies|http://www.apache.org/legal/resolved.html]
+. See the *LICENSE.txt* file contained in each release artifact for
+applicable licenses.
+
+<a name="Downloads-{anchor:v23}ApacheJackrabbit2.3.6"></a>
+## {anchor:v23}Apache Jackrabbit 2.3.6
+
+Apache Jackrabbit 2.3 is an unstable series of releases cut directly from
+Jackrabbit trunk, with a focus on new features and other improvements. For
+production use we recommend the [latest stable 2.2 release](#v22.html)
+.
+
+See the [full release notes](http://www.apache.org/dist/jackrabbit/2.3.6/RELEASE-NOTES.txt)
+ for more details.
+
+* [jackrabbit-2.3.6-src.zip](http://www.apache.org/dyn/closer.cgi/jackrabbit/2.3.6/jackrabbit-2.3.6-src.zip)
+ (512B, source zip, [PGP signature|http://www.apache.org/dist/jackrabbit/2.3.6/jackrabbit-2.3.6-src.zip.asc]
+)
+ SHA1 checksum: *e6016eb8165b19db3e5d86cd8b73be9f5fa99f35*
+ MD5 checksum: *676ee9b6fa704faf18f6dbb8a40aa3e6*
+
+* [jackrabbit-standalone-2.3.6.jar](http://www.apache.org/dyn/closer.cgi/jackrabbit/2.3.6/jackrabbit-standalone-2.3.6.jar)
+ (43M, standalone server, [PGP signature|http://www.apache.org/dist/jackrabbit/2.3.6/jackrabbit-standalone-2.3.6.jar.asc]
+)
+ SHA1 checksum: *0876215d99fe8aabd6a3e06e0b1c9d60a0c3b547*
+ MD5 checksum: *48d3533b60fbf3d2999a84404be37819*
+
+* [jackrabbit-webapp-2.3.6.war](http://www.apache.org/dyn/closer.cgi/jackrabbit/2.3.6/jackrabbit-webapp-2.3.6.war)
+ (24M, web application, [PGP signature|http://www.apache.org/dist/jackrabbit/2.3.6/jackrabbit-webapp-2.3.6.war.asc]
+)
+ SHA1 checksum: *d86aaa707d280052c31a7c59cb1d00402cdd2c86*
+ MD5 checksum: *c5b239b9932588539791ec41d3888e53*
+
+* [jackrabbit-jca-2.3.6.rar](http://www.apache.org/dyn/closer.cgi/jackrabbit/2.3.6/jackrabbit-jca-2.3.6.rar)
+ (512B, JCA resource adapter, [PGP signature|http://www.apache.org/dist/jackrabbit/2.3.6/jackrabbit-jca-2.3.6.rar.asc]
+)
+ SHA1 checksum: *415f894e1b4117da6deb9829e06ab02f9ef7dcfd*
+ MD5 checksum: *9dc6fbad2256c6fb9043b4714121c48b*
+
+<a name="Downloads-{anchor:v22}ApacheJackrabbit2.2.10"></a>
+## {anchor:v22}Apache Jackrabbit 2.2.10
+
+Apache Jackrabbit 2.2.10 is patch release that contains fixes and
+improvements over previous 2.2.x releases. This release is fully compatible
+with earlier 2.x.x releases.
+
+See the [full release notes](http://www.apache.org/dist/jackrabbit/2.2.10/RELEASE-NOTES.txt)
+ for more details.
+
+* [jackrabbit-2.2.10-src.zip](http://www.apache.org/dyn/closer.cgi/jackrabbit/2.2.10/jackrabbit-2.2.10-src.zip)
+ (10M, source zip, [PGP signature|http://www.apache.org/dist/jackrabbit/2.2.10/jackrabbit-2.2.10-src.zip.asc]
+)
+ SHA1 checksum: *d0e80e02f099e15cf91785ec25dc0c2128152930*
+ MD5 checksum: *89008240f50e2b3819b00b429d45247e*
+
+* [jackrabbit-standalone-2.2.10.jar](http://www.apache.org/dyn/closer.cgi/jackrabbit/2.2.10/jackrabbit-standalone-2.2.10.jar)
+ (33M, standalone server, [PGP signature|http://www.apache.org/dist/jackrabbit/2.2.10/jackrabbit-standalone-2.2.10.jar.asc]
+)
+ SHA1 checksum: *af77d3d5db6d52471d0e4b4662a1080ce42c26ec*
+ MD5 checksum: *bcc017ed51227bb208da5f335d3e157c*
+
+* [jackrabbit-webapp-2.2.10.war](http://www.apache.org/dyn/closer.cgi/jackrabbit/2.2.10/jackrabbit-webapp-2.2.10.war)
+ (20M, web application, [PGP signature|http://www.apache.org/dist/jackrabbit/2.2.10/jackrabbit-webapp-2.2.10.war.asc]
+)
+ SHA1 checksum: *5c2209489f2482042d712eefa716d345b6ed679e*
+ MD5 checksum: *7cd56f485d0d73fefac5fe06173ab3e6*
+
+* [jackrabbit-jca-2.2.10.rar](http://www.apache.org/dyn/closer.cgi/jackrabbit/2.2.10/jackrabbit-jca-2.2.10.rar)
+ (25M, JCA resource adapter, [PGP signature|http://www.apache.org/dist/jackrabbit/2.2.10/jackrabbit-jca-2.2.10.rar.asc]
+)
+ SHA1 checksum: *42058acb2eeb49f71e5be8135da07a7809647258*
+ MD5 checksum: *c32054a0dceb78de0be1f11b9bf0c314*
+
+<a name="Downloads-{anchor:v21}ApacheJackrabbit2.1.6"></a>
+## {anchor:v21}Apache Jackrabbit 2.1.6
+
+Apache Jackrabbit 2.1.6 is a bug fix release that fixes issues reported
+against previous releases. This release is fully compatible with the
+earlier 2.1.x releases.
+
+See the [full release notes](http://www.apache.org/dist/jackrabbit/2.1.6/RELEASE-NOTES.txt)
+ for more details.
+
+* [jackrabbit-2.1.6-src.zip](http://www.apache.org/dyn/closer.cgi/jackrabbit/2.1.6/jackrabbit-2.1.6-src.zip)
+ (6.5M, source zip, [PGP signature|http://www.apache.org/dist/jackrabbit/2.1.6/jackrabbit-2.1.6-src.zip.asc]
+)
+ SHA1 checksum: *dc8bc82bca06292a3dd21ba3859da4c1a911daac*
+ MD5 checksum: *0f8b5224454937d3a2c3ed9b12a50e32*
+
+* [jackrabbit-standalone-2.1.6.jar](http://www.apache.org/dyn/closer.cgi/jackrabbit/2.1.6/jackrabbit-standalone-2.1.6.jar)
+ (32M, standalone server, [PGP signature|http://www.apache.org/dist/jackrabbit/2.1.6/jackrabbit-standalone-2.1.6.jar.asc]
+)
+ SHA1 checksum: *fdef08602dbe3ee83a31febbbb1ca30e0d82c632*
+ MD5 checksum: *ca2f261c10d8313938492afa45fc0317*
+
+* [jackrabbit-webapp-2.1.6.war](http://www.apache.org/dyn/closer.cgi/jackrabbit/2.1.6/jackrabbit-webapp-2.1.6.war)
+ (22M, web application, [PGP signature|http://www.apache.org/dist/jackrabbit/2.1.6/jackrabbit-webapp-2.1.6.war.asc]
+)
+ SHA1 checksum: *c60039fc89a33fda2784872be6f83652213c7664*
+ MD5 checksum: *7f7569eaafa1a879b8cd62eca4ddb3c8*
+
+* [jackrabbit-jca-2.1.6.rar](http://www.apache.org/dyn/closer.cgi/jackrabbit/2.1.6/jackrabbit-jca-2.1.6.rar)
+ (20M, JCA resource adapter, [PGP signature|http://www.apache.org/dist/jackrabbit/2.1.6/jackrabbit-jca-2.1.6.rar.asc]
+)
+ SHA1 checksum: *cc6849e837d8f2a6ed217de706c56c0e5f7028b1*
+ MD5 checksum: *a7037c012e35c43675394db127b5f0c5*
+
+<a name="Downloads-{anchor:v20}ApacheJackrabbit2.0.5"></a>
+## {anchor:v20}Apache Jackrabbit 2.0.5
+
+Apache Jackrabbit 2.0.5 is a bug fix release that fixes issues reported
+against previous releases. This release is fully compatible with the
+earlier 2.0.x releases.
+
+See the [full release notes](http://www.apache.org/dist/jackrabbit/2.0.5/RELEASE-NOTES.txt)
+ for more details.
+
+* [jackrabbit-2.0.5-src.zip](http://www.apache.org/dyn/closer.cgi/jackrabbit/2.0.5/jackrabbit-2.0.5-src.zip)
+ (6.2M, source zip, [PGP signature|http://www.apache.org/dist/jackrabbit/2.0.5/jackrabbit-2.0.5-src.zip.asc]
+)
+ SHA1 checksum: *e1b29e484ed2dde5ec1efc395e4035c44d6ea61f*
+ MD5 checksum: *5463a14a95fe18a8da7a6e4861751d4a*
+
+* [jackrabbit-standalone-2.0.5.jar](http://www.apache.org/dyn/closer.cgi/jackrabbit/2.0.5/jackrabbit-standalone-2.0.5.jar)
+ (41M, standalone server, [PGP signature|http://www.apache.org/dist/jackrabbit/2.0.5/jackrabbit-standalone-2.0.5.jar.asc]
+)
+ SHA1 checksum: *8ab7acebbc402f9092128fd4552110f03c0ffb53*
+ MD5 checksum: *91cd68164a4f6b738578e9a288ab2bc5*
+
+* [jackrabbit-webapp-2.0.5.war](http://www.apache.org/dyn/closer.cgi/jackrabbit/2.0.5/jackrabbit-webapp-2.0.5.war)
+ (29M, web application, [PGP signature|http://www.apache.org/dist/jackrabbit/2.0.5/jackrabbit-webapp-2.0.5.war.asc]
+)
+ SHA1 checksum: *4d70a6bfd0d7b9f18a59803e8f178711d4f9a0cf*
+ MD5 checksum: *5c7a93ff714685383bf8a54b5f28e7d5*
+
+* [jackrabbit-jca-2.0.5.rar](http://www.apache.org/dyn/closer.cgi/jackrabbit/2.0.5/jackrabbit-jca-2.0.5.rar)
+ (26M, JCA resource adapter, [PGP signature|http://www.apache.org/dist/jackrabbit/2.0.5/jackrabbit-jca-2.0.5.rar.asc]
+)
+ SHA1 checksum: *ea72a4b9e8ea0c0fa5047b976ec8430deff2dc35*
+ MD5 checksum: *406252030cc64ca7203b67c671f71953*
+
+<a name="Downloads-{anchor:v16}ApacheJackrabbit1.6.5"></a>
+## {anchor:v16}Apache Jackrabbit 1.6.5
+
+Apache Jackrabbit 1.6.5 is a bug fix release that fixes issues reported
+against previous releases. This release is backwards-compatible with the
+earlier 1.6.x releases, but contains a change in persistence format that
+makes it impossible to downgrade to releases earlier than 1.6.2 after a
+repository has been upgraded. A full backup of the repository is
+recommended before this upgrade.
+
+{note}This patch release marks the end of active maintenance of the
+Jackrabbit 1.6 branch. All users are encouraged to upgrade to the more
+recent Jackrabbit 2.x versions.{note}
+
+See the [full release notes](http://www.apache.org/dist/jackrabbit/1.6.5/RELEASE-NOTES.txt)
+ for more details.
+
+* [jackrabbit-1.6.5-src.zip](http://www.apache.org/dyn/closer.cgi/jackrabbit/1.6.5/jackrabbit-1.6.5-src.zip)
+ (5.7M, source zip, [PGP signature|http://www.apache.org/dist/jackrabbit/1.6.5/jackrabbit-1.6.5-src.zip.asc]
+)
+ SHA1 checksum: *4fa1e032f9b641fbc5c9ff8d6ba76fdb58b539ba*
+ MD5 checksum: *c54349f1f00e4d0f95f7e16dd3f5da11*
+
+* [jackrabbit-standalone-1.6.5.jar](http://www.apache.org/dyn/closer.cgi/jackrabbit/1.6.5/jackrabbit-standalone-1.6.5.jar)
+ (21M, standalone server, [PGP signature|http://www.apache.org/dist/jackrabbit/1.6.5/jackrabbit-standalone-1.6.5.jar.asc]
+)
+ SHA1 checksum: *a9be78279c3987a7550d91f173b42bba9f801c4c*
+ MD5 checksum: *6efcdd934e22b5dd5183638be7202a1f*
+
+* [jackrabbit-webapp-1.6.5.war](http://www.apache.org/dyn/closer.cgi/jackrabbit/1.6.5/jackrabbit-webapp-1.6.5.war)
+ (14M, web application, [PGP signature|http://www.apache.org/dist/jackrabbit/1.6.5/jackrabbit-webapp-1.6.5.war.asc]
+)
+ SHA1 checksum: *ea352bce5528c819fec9a534838f1852e4c31bb5*
+ MD5 checksum: *642daded0a09e19544b510cd390ce621*
+
+* [jackrabbit-jca-1.6.5.rar](http://www.apache.org/dyn/closer.cgi/jackrabbit/1.6.5/jackrabbit-jca-1.6.5.rar)
+ (13M, JCA resource adapter, [PGP signature|http://www.apache.org/dist/jackrabbit/1.6.5/jackrabbit-jca-1.6.5.rar.asc]
+)
+ SHA1 checksum: *3d5934b96f931c21da7bcffdf2c04999396c5d83*
+ MD5 checksum: *bb6c29df607ac7a6b117da4fc9aa3683*
+
+<a name="Downloads-{anchor:archive}ReleaseArchive"></a>
+## {anchor:archive} Release Archive
+
+Only current recommended releases are available on the main distribution
+site and its mirrors. Older releases are available from the [archive download site](http://archive.apache.org/dist/jackrabbit/)
+.
+
+<a name="Downloads-{anchor:verify}Verify"></a>
+## {anchor:verify} Verify
+
+It is essential that you verify the integrity of the downloaded files using
+the PGP signatures or MD5 and SHA1 checksums. Please read [Verifying Apache HTTP Server Releases](http://httpd.apache.org/dev/verification.html)
+ for more information on why you should verify our releases.
+
+The PGP signatures can be verified using PGP or GPG. First download the [KEYS](http://www.apache.org/dist/jackrabbit/KEYS)
+ file as well as the *.asc* signature files for the relevant release
+packages. Make sure you get these files from the [main distribution directory|http://www.apache.org/dist/jackrabbit/]
+, rather than from a mirror. Then verify the signatures using
+
+
+ % pgpk -a KEYS
+ % pgpv jackrabbit-X.Y.Z-src.zip.asc
+
+
+or
+
+
+ % pgp -ka KEYS
+ % pgp jackrabbit-X.Y.Z-src.zip.asc
+
+
+or
+
+
+ % gpg --import KEYS
+ % gpg --verify jackrabbit-X.Y.Z-src.zip.asc
+
+
+Alternatively, you can verify the MD5 or SHA1 checksums on the files. For
+checking the MD5 checksums, use the program called *md5* or *md5sum*
+included in many Unix distributions. The similar program for SHA1 is called
+*sha1sum*. It is also available as part of the [GNU core utilities](http://www.gnu.org/software/coreutils/)
+. Windows users can get binary md5 programs from [here|http://www.fourmilab.ch/md5/]
+, [here|http://www.pc-tools.net/win32/md5sums/]
+, or [here|http://www.slavasoft.com/fsum/]
+.
Propchange: jackrabbit/site/trunk/content/downloads.mdtext
------------------------------------------------------------------------------
svn:eol-style = native
Added: jackrabbit/site/trunk/content/embedded-repository.cwiki
URL: http://svn.apache.org/viewvc/jackrabbit/site/trunk/content/embedded-repository.cwiki?rev=1229679&view=auto
==============================================================================
--- jackrabbit/site/trunk/content/embedded-repository.cwiki (added)
+++ jackrabbit/site/trunk/content/embedded-repository.cwiki Tue Jan 10 18:50:59 2012
@@ -0,0 +1,201 @@
+You can run Jackrabbit in embedded mode inside your application if you only (or mostly) access a repository from that one application. In this deployment model the Jackrabbit dependencies are included directly in your classpath and your application is in full control of the repository lifecycle. To use this deployment model you need to add the appropriate dependencies to your application and include a few lines of Jackrabbit-specific code to start and stop a repository. You can then use the standard JCR API to access and manage content inside the repository.
+
+This page describes how to embed Jackrabbit in your application.
+
+{toc:minLevel=2}
+
+h2. Jackrabbit dependencies
+
+To use Jackrabbit in embedded mode you need to make sure that the JCR API and all required Jackrabbit libraries are included in your classpath. If you use [Maven 2|http://maven.apache.org/], you can achieve this by specifying the following dependencies.
+
+{code:xml}
+<dependency>
+ <groupId>javax.jcr</groupId>
+ <artifactId>jcr</artifactId>
+ <version>1.0</version>
+</dependency>
+<dependency>
+ <groupId>org.apache.jackrabbit</groupId>
+ <artifactId>jackrabbit-core</artifactId>
+ <version>1.5.0</version>
+ <exclusions>
+ <exclusion>
+ <groupId>commons-logging</groupId>
+ <artifactId>commons-logging</artifactId>
+ </exclusion>
+ </exclusions>
+</dependency>
+<dependency>
+ <groupId>org.slf4j</groupId>
+ <artifactId>jcl-over-slf4j</artifactId>
+ <version>1.5.3</version>
+</dependency>
+<dependency>
+ <groupId>org.slf4j</groupId>
+ <artifactId>slf4j-log4j12</artifactId>
+ <version>1.5.3</version>
+</dependency>
+{code}
+
+The jcr dependency includes the JCR 1.0 API in your classpath. You need to explicitly declare this dependency as in jackrabbit-core the JCR API dependency scope is _provided_ to work better in deployment models where the JCR API is shared between multiple applications.
+
+The jackrabbit-core dependency pulls in the Jackrabbit content repository implementation and a set of transitive dependencies needed by Jackrabbit. See the [Downloads] page for the latest available version.
+
+Jackrabbit uses the [SLF4J|http://www.slf4j.org/] for logging and leaves it up to the embedding application to decide which underlying logging library to use. In the example above we use the slf4j-log4j12 library which uses [log4j 1.2|http://logging.apache.org/log4j/1.2/] for handling the log messages. Note that the commons-logging dependency (which is a transitive dependency from [Apache POI|http://poi.apache.org/]) is explicitly replaced with the jcl-over-slf4j dependency that routes also all [Commons Logging|http://commons.apache.org/logging/] log messages through the selected SLF4J implementation. Jackrabbit 1.5.x uses SLF4J version 1.5.3.
+
+The full set of compile-scope dependencies included by the above declaration is shown below. If you use a build tool like [Ant|http://ant.apache.org/] where you need to explicitly include all dependencies, you can use this list to correctly configure your classpath.
+
+{code}
++- javax.jcr:jcr:jar:1.0:compile
++- org.apache.jackrabbit:jackrabbit-core:jar:1.5.0:compile
+| +- concurrent:concurrent:jar:1.3.4:compile
+| +- commons-collections:commons-collections:jar:3.1:compile
+| +- commons-io:commons-io:jar:1.4:compile
+| +- org.apache.jackrabbit:jackrabbit-api:jar:1.5.0:compile
+| +- org.apache.jackrabbit:jackrabbit-jcr-commons:jar:1.5.0:compile
+| +- org.apache.jackrabbit:jackrabbit-spi-commons:jar:1.5.0:compile
+| +- org.apache.jackrabbit:jackrabbit-spi:jar:1.5.0:compile
+| +- org.apache.jackrabbit:jackrabbit-text-extractors:jar:1.5.0:compile
+| | +- org.apache.poi:poi:jar:3.0.2-FINAL:compile
+| | +- org.apache.poi:poi-scratchpad:jar:3.0.2-FINAL:compile
+| | +- pdfbox:pdfbox:jar:0.7.3:compile
+| | | +- org.fontbox:fontbox:jar:0.1.0:compile
+| | | \- org.jempbox:jempbox:jar:0.2.0:compile
+| | \- net.sourceforge.nekohtml:nekohtml:jar:1.9.7:compile
+| | \- xerces:xercesImpl:jar:2.8.1:compile
+| | \- xml-apis:xml-apis:jar:1.3.03:compile
+| +- org.slf4j:slf4j-api:jar:1.5.3:compile
+| +- org.apache.lucene:lucene-core:jar:2.3.2:compile
+| \- org.apache.derby:derby:jar:10.2.1.6:compile
++- org.slf4j:jcl-over-slf4j:jar:1.5.3:compile
+\- org.slf4j:slf4j-log4j12:jar:1.5.3:compile
+ \- log4j:log4j:jar:1.2.14:compile
+{code}
+
+Note that some of the transitive dependencies listed above may conflict with some other dependencies of our application. In such cases you may want to consider switching to a deployment model that uses separate class loaders for your application and the Jackrabbit content repository.
+
+h2. Starting the repository
+
+Once you have your classpath configured you can start the repository with the following piece of code.
+
+{code:java}
+import javax.jcr.Repository;
+import org.apache.jackrabbit.core.RepositoryImpl;
+import org.apache.jackrabbit.core.config.RepositoryConfig;
+
+String xml = "/path/to/repository/configuration.xml";
+String dir = "/path/to/repository/directory";
+RepositoryConfig config = RepositoryConfig.create(xml, dir);
+Repository repository = RepositoryImpl.create(config);
+{code}
+
+See the [Jackrabbit Configuration] page for more information on repository configuration. See the [RepositoryConfig|http://jackrabbit.apache.org/api/1.5/org/apache/jackrabbit/core/config/RepositoryConfig.html] and [RepositoryImpl|http://jackrabbit.apache.org/api/1.5/org/apache/jackrabbit/core/RepositoryImpl.html] javadocs for more details on these classes.
+
+h2. Shutting down the repository
+
+When your application no longer needs the content repository, you can shut it down with the following code.
+
+{code:java}
+((RepositoryImpl) repository).shutdown();
+{code}
+
+This will forcibly close all open sessions and make sure that all repository content is safely stored on disk.
+
+h2. The TransientRepository class
+
+Jackrabbit comes with a [TransientRepository|http://jackrabbit.apache.org/api/1.5/org/apache/jackrabbit/core/TransientRepository.html] class that makes it even easier to get started with a content repository. This class is especially handy for quick prototyping, but using the RepositoryImpl class as described above gives you better control over the repository lifecycle and is typically a better alternative for production code.
+
+{code:java}
+import javax.jcr.Repository;
+import org.apache.jackrabbit.core.TransientRepository;
+
+Repository repository = new TransientRepository();
+{code}
+
+This creates a repository instance that starts up when the first session is created and automatically shuts down when the last session is closed. By default the repository will be created in a "jackrabbit" subdirectory using a default configuration file in "jackrabbit/repository.xml". See the TransientRepository javadocs for the ways to override these defaults.
+
+h2. Enabling remote access
+
+Even if you mostly use the content repository in embedded mode within your application, it may occasionally be useful to be able to access the repository for example from an external administration tool while your application is still running. You can use the jackrabbit-jcr-rmi library to make this possible. To do this, you first need to add the appropriate dependency.
+
+{code:xml}
+<dependency>
+ <groupId>org.apache.jackrabbit</groupId>
+ <artifactId>jackrabbit-jcr-rmi</artifactId>
+ <version>1.5.0</version>
+</dependency>
+{code}
+
+Make sure that you have [rmiregistry|http://java.sun.com/j2se/1.5.0/docs/tooldocs/solaris/rmiregistry.html] running, and use the following code to export the repository. Note that you need to include the JCR API and the jackrabbit-jcr-rmi libraries in the rmiregistry classpath for the binding to work without extra RMI codebase settings.
+
+{code:java}
+import java.rmi.Naming;
+import org.apache.jackrabbit.rmi.server.RemoteAdapterFactory;
+import org.apache.jackrabbit.rmi.server.RemoteRepository;
+import org.apache.jackrabbit.rmi.jackrabbit.JackrabbitRemoteAdapterFactory;
+
+String url = "//localhost/javax/jcr/Repository"; // RMI URL of the repository
+RemoteAdapterFactory factory = new JackrabbitRemoteAdapterFactory();
+RemoteRepository remote = factory.getRemoteRepository(repository);
+Naming.bind(url, remote);
+{code}
+
+Use the following code to remote the repository binding from the RMI registry before you shutdown the repository.
+
+{code:java}
+Naming.unbind(url);
+{code}
+
+You need to keep a direct reference to the RemoteRepository instance in your code until you call Naming.unbind as otherwise it could get garbage collected before a remote client connects to it.
+
+See the [Repository Server] page for instructions on how to access such a remote repository.
+
+h2. Embedded repository in a web application
+
+If your want to embed Jackrabbit in a web application, you can use the classes in the jackrabbit-jcr-servlet library to avoid the above startup and shutdown code. To do this, you first need to include jackrabbit-jcr-servlet as a dependency.
+
+{code:xml}
+<dependency>
+ <groupId>org.apache.jackrabbit</groupId>
+ <artifactId>jackrabbit-jcr-servlet</artifactId>
+ <version>1.5.0</version>
+</dependency>
+{code}
+
+Then you can instruct the servlet container to automatically start and stop the repository as a part of your webapp lifecycle by including the following servlet configuration in your web.xml file.
+
+{code:xml}
+<servlet>
+ <servlet-name>ContentRepository</servlet-name>
+ <servlet-class>org.apache.jackrabbit.servlet.jackrabbit.JackrabbitRepositoryServlet</servlet-class>
+ <load-on-startup>1</load-on-startup>
+</servlet>
+{code}
+
+See the [JackrabbitRepositoryServlet|http://jackrabbit.apache.org/api/1.5/org/apache/jackrabbit/servlet/jackrabbit/JackrabbitRepositoryServlet.html] javadocs for the available configuration options.
+
+You can then access the repository in your own servlet classes using the following piece of code without worrying about the repository lifecycle.
+
+{code:java}
+import javax.jcr.Repository;
+import org.apache.jackrabbit.servlet.ServletRepository;
+
+Repository repository = new ServletRepository(this); // "this" is the containing servlet
+{code}
+
+The benefit of this approach over directly using the RepositoryImpl or TransientRepository classes as described above is that you can later on switch to a different deployment model without any code changes simply by modifying the servlet configuration in your web.xml.
+
+With this approach it is also easier to make your repository remotely available. Add the following configuration to your web.xml and your repository is automatically made available as a remote repository at .../rmi in the URL space of your webapp.
+
+{code:xml}
+<servlet>
+ <servlet-name>RemoteRepository</servlet-name>
+ <servlet-class>org.apache.jackrabbit.servlet.remote.RemoteBindingServlet</servlet-class>
+</servlet>
+<servlet-mapping>
+ <servlet-name>RemoteRepository</servlet-name>
+ <url-pattern>/rmi</url-pattern>
+</servlet-mapping>
+{code}
+
+Note that you also need the jackrabbit-jcr-rmi dependency in your application for the above configuration to work.
\ No newline at end of file
Propchange: jackrabbit/site/trunk/content/embedded-repository.cwiki
------------------------------------------------------------------------------
svn:eol-style = native