On Wed, Feb 17, 2010 at 5:46 PM, Carsten Ziegeler <[email protected]> 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 > [email protected] >
