Hi This thread indeed raises the question, why Oak has to come up with something (the Whiteboard) that is almost but not quite like OSGi instead of going all the way through ?
As a stop-gap measure, instead of going full-OSGi you could also just leverage the feature, that you really need: The service registry and base on something like Karl Pauls' µServices [2] and PojoSR [3] Interestingly, when I started with what became Apache Sling I worked on a thing called the "Extension Frameworkg for JCR Repositories" [1] until it turned out that it basically would be reinventing OSGi … and so Sling became an OSGi application. Regards Felix [1] http://svn.apache.org/repos/asf/jackrabbit/sandbox/inactive/extension-framework/ [2] http://www.pro-vision.de/content/medialib/pro-vision/production/adaptto/2013/adaptto2013-osgi--services-karl-pauls-pdf/_jcr_content/renditions/rendition.download_attachment.file/adaptto2013-osgi--services-karl-pauls.pdf [3] http://code.google.com/p/pojosr/ Am 09.02.2014 um 10:05 schrieb Davide Giannella <[email protected]>: > On Sat, Feb 8, 2014 at 6:58 PM, Tobias Bocanegra <[email protected]> wrote: >> ... >> ps: I still think we should turn the problem around, and make >> everything OSGi services and start a small OSGi container for the >> runtime :-) > > I was thinking the same tonight. I was going to ask why (any > historical decisions) Oak in the oak-run doesn't use a simple > bundled-up OSGi container and runs the related jar, that are already > OSGi bundles, in it. > > It would make for example a lot easier to inject a CommitHook like a > custom index. So far the only way to achieve so is to recompile the > oak-run adding .with(new MyIndexProvider()) while I'd rather add a > Service implementation the OSGi whiteboard. > > D.
