jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Guggisberg <stefan.guggisb...@gmail.com>
Subject Re: [jr3] Plugin architecture
Date Thu, 18 Feb 2010 09:45:46 GMT
On Wed, Feb 17, 2010 at 5:46 PM, Carsten Ziegeler <cziegeler@apache.org> wrote:
> Jukka Zitting wrote:
>> Hi,
>>
>> 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?
>>
> Just a comment from the peanut gallery....
>
> In my opinion OSGi is the perfect fit for a plugin architecture and it
> solves the problems you mention above.

and causes quite a few others, at least that's my personal experience
with felix, equinox and sling ;)

i don't mind providing osgi support at a higher level, the core however
should IMO not have any osgi-dependenciesi.

cheers
stefan

> But my important point is, whatever container you are picking up, use
> exactly this one. Don't try to make it usable with several containers.
>
> Carsten
> --
> Carsten Ziegeler
> cziegeler@apache.org
>

Mime
View raw message