jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tommaso Teofili <tommaso.teof...@gmail.com>
Subject Re: EditorProvider after Oak construction
Date Fri, 31 Jan 2014 14:55:47 GMT
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 <dpfister@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 <dpfister@adobe.com<mailto:
> dpfister@adobe.com>> wrote:
>
> Hi Jukka,
>
> On Jan 9, 2014, at 4:39 PM, Jukka Zitting <jukka.zitting@gmail.com<mailto:
> jukka.zitting@gmail.com>> wrote:
>
> Hi,
>
> On Thu, Jan 9, 2014 at 10:29 AM, Dominique Pfister <dpfister@adobe.com
> <mailto:dpfister@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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message