|Jukka Zitting||Feb 17, 2010 8:05 am|
|Carsten Ziegeler||Feb 17, 2010 8:46 am|
|Adam Foltzer||Feb 17, 2010 5:59 pm|
|Justin Edelson||Feb 17, 2010 8:03 pm|
|Thomas Müller||Feb 18, 2010 12:19 am|
|Stefan Guggisberg||Feb 18, 2010 1:37 am|
|Stefan Guggisberg||Feb 18, 2010 1:45 am|
|Carsten Ziegeler||Feb 18, 2010 1:53 am|
|Bertrand Delacretaz||Feb 18, 2010 2:01 am|
|Guo Du||Feb 18, 2010 3:54 am|
|Alexander Klimetschek||Feb 18, 2010 4:05 am|
|Alexander Klimetschek||Feb 18, 2010 4:07 am|
|Felix Meschberger||Feb 18, 2010 4:34 am|
|Guo Du||Feb 18, 2010 4:52 am|
|Alexander Klimetschek||Feb 18, 2010 4:59 am|
|Justin Edelson||Feb 18, 2010 5:14 am|
|Thomas Müller||Feb 18, 2010 6:34 am|
|Marcel Reutegger||Feb 19, 2010 6:39 am|
|Michael Dürig||Feb 20, 2010 6:10 am|
|Subject:||[jr3] Plugin architecture|
|From:||Jukka Zitting (jukk...@gmail.com)|
|Date:||Feb 17, 2010 8:05:37 am|
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.
WDYT? Any other ideas on what we should do in this are?