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
