jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominique Pfister <dpfis...@adobe.com>
Subject Re: EditorProvider after Oak construction
Date Thu, 09 Jan 2014 17:00:52 GMT
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