jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tobias Bocanegra <tri...@apache.org>
Subject Re: Make "Whiteboard" accessible through ContentRepository
Date Sat, 08 Feb 2014 18:58:09 GMT

On Sat, Feb 8, 2014 at 7:26 AM, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> Hi,
> On Sat, Feb 8, 2014 at 2:42 AM, Tobias Bocanegra <tripod@apache.org> wrote:
>> currently there is not way to access the whiteboard from within the
>> content repository - only if it's added from the outside to the
>> plugins.
> That's the intended design. The whiteboard mechanism is an abstraction
> of the OSGi BundleContext and works similarly; i.e. the code that
> instantiates/manages a component is expected to pass the
> whiteboard/context to that component if/when needed.

ok, then what we need it the pendant to the OSGi service registry, or
to the SlingHelper stuff. I.e. a mechanism where I can lookup any

>> For example, I would need access to it from within a LoginModule.
> If you already have access to a ContentRepository, then why not use
> the same mechanism to pass the Whiteboard instead of using a
> ContentRepository method for that?

thats what I mean, add the whiteboard from 'Oak.class' to the
constructor to ContentRepositoryImpl.

The problem at hand is, that users can provide a service that is used
in one of the login modules. so eventually we need to pass the osgi
whiteboard into the login module. which is easy. but otoh, in the
non-osgi case, a unique whiteboard instance should be passed. which is
not so easy. IMO there should only be 1 whiteboard instance per
"system" (or it should base on a global service registry). for OSGi
this is not a problem, because they all rely on the same service
registry. but for the non-osgi usecase.

one workaround idea I tested in [0] by introducing "WhiteboardAware"
interface (better name welcome). when such a instance is added to the
Oak instance via a with() method, it oak will push the whiteboard to

regards, toby

ps: I still think we should turn the problem around, and make
everything OSGi services and start a small OSGi container for the
runtime :-)

[0] https://github.com/tripodsan/jackrabbit-oak/commit/8026bd44cf47879c67f7875bc08247a4eb7e501f

> BR,
> Jukka Zitting

View raw message