Regardless of whether we go with a microkernel approach as discussed
in the other thread, making Jackrabbit more modular and extensible
would be quite useful. Besides the design benefits, plugin
architectures typically also increase community participation as they
make it easier to customize or extend the product.

The current architecture already provides a number of extension points
via various core interfaces and configuration points, but they are a
bit cumbersome to use and not always in the points where you'd want
them to be. Here's what I have in mind for what we could do about
this:

* dynamic configuration: The current XML-based configuration mechanism
needs to be updated whenever new extension points are introduced and
makes it difficult to support dynamic plugin environments like OSGi or
IoC containers.

* higher level extension points: Most of our extension points are
currently deep down at the bottom of the Jackrabbit architecture
(PersistenceManager, Journal, FileSystem, SearchIndex, etc.). It would
be useful to offer also higher level constructs like Repository and
Session lifecycle listeners or transaction boundary checkers to be
injected into the system.

* whiteboard pattern: Instead of the custom context objects
(PMContext, ClusterContext, etc.) and related init calls that
statically wire our components together we should look at implementing
more dynamic whiteboards from where all components could do on-demand
lookups for the things they need.