jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@adobe.com>
Subject Re: Oak plugin model
Date Wed, 16 May 2012 10:52:13 GMT

With my OSGi hat on, this is ok with a few caveats:

* Separate the (service) interfaces from implementations in distinct packages. It has been
one the biggest annoyances with the current Jackrabbit implementation, that such plugin interfaces
are generally mixed with implementations in the same package (apart from signatures often
time referring to implementation classes).

* Make sure to consider livecycle: In a traditional application which starts and stops, a
service might be available from the start till the end of the application. In a modular application
runnuning an OSGi framework a plugin (service) may come and go at any time. This should be
accounted for in some way or another.


Am 15.05.2012 um 18:18 schrieb Jukka Zitting:

> Hi,
> When we talk about Oak and about where in our stack a particular piece
> of functionality should be implemented, we often tend to approach the
> design as a layered stack of components from oak-jcr to oak-core and
> on to the underlying implementation. Possible extra features are
> usually presented as either new functionality in one of the existing
> components or as an extra layer in between or on top of this stack.
> This linear top-down view of dependencies seriously limits the
> architectural freedom and potential for extensibility we have. I've
> brought this up a few times in the context of other discussions, but I
> wanted to raise it also as a general concept to make sure we're all on
> the same page.
> To make this non-layered approach to Oak architecture more obvious, I
> outlined this idea in a diagram [1] that shows various potential
> features as pluggable extensions. Such an approach provides a nice
> third alternative to the kinds of discussions where we've been
> debating whether a particular feature (like name mapping, query
> parsing, etc.) should be located in oak-jcr or oak-core. By treating
> such functionality as pluggable extensions, accessed through well
> defined service provider interfaces, we get to keep the main Oak API
> clean and simple (e.g. no need for it to cover concepts like a
> namespace registry or an abstract query tree) and make the overall
> system much more modular and easier to customize.
> Ultimately such extra plugin components may well end up as separate
> Maven components, but until the related service interfaces and plugin
> boundaries are well defined it's better to keep all such code together
> and simply use Java package boundaries to separate them. That's the
> rationale behind the .oak.plugins package I recently created in
> oak-core, and I propose that we'll start moving also other pluggable
> parts (like some of the query bits and applicable parts of the recent
> security work) there.
> [1] http://people.apache.org/~jukka/2012/oak-plugins.png
> BR,
> Jukka Zitting

View raw message