Hi all, I'm a bit lost about how the plugin registration is (or should be) done. I assume the goal here is to be able to register whatever Oak plugin (Editor, IndexEditor, etc.) regardless of how Oak is initialized or at least having that possible by default and I understood the idea was to leverage OSGi services to do that (new bundles having services implementing a plugin interface are registered and used by Oak as soon as they're there). I see we have the OsgiWhiteboard used in oak-core Activator for registering MBeans, the WhiteboardAuthorizableActionProvider started in the SecurityProviderImpl, the WhiteboardEditorProvider / WhiteboardIndexEditorProvider / WhiteboardIndexProvider started in the oak-jcr Activator via an OsgiWhiteboard and therefore, as far as I can see, the services should be correctly registered but it seems such whiteboard providers are never used as also Dominique noted.
I think that at least we should have such whiteboard stuff in one Activator (oak-core IMHO) rather than spread among two, also because Editor & co. are Oak APIs and not JCR stuff. Also, I think it'd be nice to add them directly in the Oak class. Regards, Tommaso 2014-01-09 Dominique Pfister <dpfis...@adobe.com>: > Hi again, > > My enthusiasm might have been a bit premature: there is actually a > WhiteboardEditorProvider in Oak that will invoke all registered OSGI > services of type EditorProvider, but it is unused (in contrast to e.g. > WhiteboardAuthorizableActionProvider). Would a simple registration of this > "special" EditorProvider in Oak.with(...) fix it? > > Thanks > Dominique > > On Jan 9, 2014, at 4:54 PM, Dominique Pfister <dpfis...@adobe.com<mailto: > dpfis...@adobe.com>> wrote: > > Hi Jukka, > > On Jan 9, 2014, at 4:39 PM, Jukka Zitting <jukka.zitt...@gmail.com<mailto: > jukka.zitt...@gmail.com>> wrote: > > Hi, > > On Thu, Jan 9, 2014 at 10:29 AM, Dominique Pfister <dpfis...@adobe.com > <mailto:dpfis...@adobe.com>> wrote: > I'm working on an application packaged as an OSGI bundle that would > perform some validation and > store some auxiliary data in a node whenever a stream is saved in one of > its properties, so I'm > thinking on creating some CommitHook (or an EditorProvider) that would be > able to compute > the auxiliary property. > > An EditorProvider is probably better for this case, as it adds less > overhead than a full CommitHook. > > Now comes the problem: in my setup, the Oak repository is created with > some Hooks/Providers > on startup, and AFAICS only Observer's can be added/removed after that, is > this correct? > > If you expose your EditorProvider as an OSGi service, Oak should > automatically pick it up and apply it to any new commits. At least > that's the intention; I'm not sure if the OSGi binding yet does that. > > Great news, that's exactly what I hoped for! > > Cheers > Dominique > > > BR, > > Jukka Zitting > >
