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 Mon, 10 Feb 2014 06:01:18 GMT
Hi,

On Sun, Feb 9, 2014 at 9:40 AM, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> Hi,
>
> On Sat, Feb 8, 2014 at 1:58 PM, Tobias Bocanegra <tripod@apache.org> wrote:
>> ok, then what we need it the pendant to the OSGi service registry, [...]
>
> s/the pendant/a dependency/? I'm not sure I understood this correctly.
>
>> I.e. a mechanism where I can lookup any service.
>
> This sounds like an XY problem, i.e. you're proposing a solution
> without describing the problem you're trying to solve.

ok...using Sling/Felix quite a lot, I'm used to the possibility to
create a Service that can have references to any other exported
Service via its ComponentContext, i.e. BundleContext, i.e underlying
OSGi service registry.

> You mentioned a LoginModule implementation. Why would it need to look
> up "any" service? Wouldn't a dependency to a specific service be
> enough/better?

sure, in the end it is a specific service. but we don't want to limit
the set of services a login module can use. IMO, it should have access
to all the ones registered. So a login module (also in the non osgi
world) should be able to retrieve the Whiteboard to get a service.
Either directly via a callback (probably the correct solution) or via
one of the classes it already can access (ContentRepository or
SecurityProvider).

>> thats what I mean, add the whiteboard from 'Oak.class' to the
>> constructor to ContentRepositoryImpl.
>
> You mean "new ContentRepositoryImpl(..., whiteboard, ...);"? Yes, we
> can do that. Though as mentioned above I'd like to understand why we
> need to do that instead of passing the whiteboard (or better, a more
> specific dependency) directly to whatever component that needs it.

you might be right, it doesn't need it, if the services that needs it
is created the correct way.

>> 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.
>
> I don't see the problem:
>
>     Whiteboard whiteboard = ...;
>     new Oak(...)
>         .with(whiteboard)
>         .with(new SomeComponent(whiteboard))
>         ....;
>
> Or perhaps I'm missing something here?

I think my problem is, that there are (were) several instances of the
'DefautlWhiteboard" created, one in Oak.java, one by the
SecurityProviderImpl.
We should make the DefaultWhiteboard implementation private to Oak.

And only allow to create Oak() with or without whiteboard, and remove
the Oak.with(Whiteboard) method. So it's clear that either we use the
external provided whiteboard, or the implicit internal one.

>> 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
>> it.
>
> Right, we can of course do that, but IMHO the above constructor
> argument pattern seems much simpler.

the problem is, that each plugin, that needs a whiteboard, should be
able to get the default one. without some helper classes, the
construction gets a bit awkward:

Oak oak = new Oak();
SecurityProvider sp = new SecurityProvider(oak.getWhiteboard());
oak.with(sp);

IMO it's better that Oak.with() pushes its whiteboard to the plugin.

>
> BR,
>
> Jukka Zitting

Mime
View raw message