Mailing-List: contact oak-dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: oak-dev@jackrabbit.apache.org
Received-SPF: pass (athena.apache.org: domain of jukka.zitting@gmail.com
 designates 209.85.214.177 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAB+dfi=mkBWk2C678spsA4f340mQRWm2guQe1oYts5B4wf63kg@mail.gmail.com>
References: 
 <CAB+dfi=Jc1iKgke1b1A2ASpHnkEbqQX67fcsODV53T0arU_fqw@mail.gmail.com>
 <CAOFYJNYfGEWBTvvOm2bTqVd3vsAVoqkBV2ugggXVrtOUMUamQg@mail.gmail.com>
 <CAB+dfikHKM5GoaUd2CSeFhVkf6JX49skLAuA=msmeg8QjRkhhQ@mail.gmail.com>
 <CAOFYJNavY4YUVeB2pJjqpFY3X-UsU0T9Ht=fyjrckS5xV00QOw@mail.gmail.com>
 <CAB+dfi=mkBWk2C678spsA4f340mQRWm2guQe1oYts5B4wf63kg@mail.gmail.com>
From: Jukka Zitting <jukka.zitting@gmail.com>
Date: Mon, 10 Feb 2014 07:31:56 -0500
Message-ID: 
 <CAOFYJNbqBFf5ZbjrK_g6+ySTacyBdsiAqgoCYTCmzaDR45C15A@mail.gmail.com>
Subject: Re: Make "Whiteboard" accessible through ContentRepository
To: Oak devs <oak-dev@jackrabbit.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

Hi,

On Mon, Feb 10, 2014 at 1:01 AM, Tobias Bocanegra <tripod@apache.org> wrote:
> 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.

The same thing works also without OSGi, you just add a new component
constructor argument or a setter and adjust the code that does the
wiring to provide that dependency to a component. I admit that doing
it this way does require changing code in two places, but it also
achieves better decoupling of the service from the way it's wired up,
i.e. the component itself doesn't have to worry about the mechanics of
the service lookup. This simplifies also things like unit test
fixtures as you can just mock the direct dependencies of a component
instead of setting up a full runtime environment.

Declarative Services in OSGi works similarly in decoupling the wiring
of services from the services themselves. A DS-based component doesn't
necessarily need to access the Component/BundleContext at all, as it
can just declare direct dependencies to all the services it needs.
Most Oak components should work the same way instead of requiring
direct access to the Whiteboard. By making the DS bind methods
explicit, you could even write a normal DS-based component that you
can also wire up statically in places like oak-run.

> 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.

See above; instead of going through the Whiteboard, I'd rather see a
component declaring direct dependencies to the services it needs. The
wiring should happen elsewhere.

> I think my problem is, that there are (were) several instances of the
> 'DefautlWhiteboard" created, one in Oak.java, one by the
> SecurityProviderImpl.

Hmm, I only see a DefaultWhiteboard instance being created in
Oak.java. SecurityProviderImpl uses OsgiWhiteboard. Did this change in
OAK-1377?

> 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.

We can do that, though one of the driving ideas behind Oak has been to
keep things like "new Oak().with(new
SomeComponent()).createContentSession()" as simple as possible.

> 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.

If this becomes a common need, i.e. there are many components that
need access to the whiteboard (instead of just a more specific set of
services, as suggested above), then I'd rather pull the whiteboard
entirely out of the Oak class, like this:

    Whiteboard whiteboard = ...;
    new Oak(...)
        .with(new SecurityProvider(whiteboard))
        .createContentRepository(whiteboard);

But as said, I think only a small subset of our components should
really need direct access to the whiteboard.

For example the authorizable action and restriction providers in
SecurityProviderImpl are composite services, that in an OSGi
deployment can/should be dynamic through the whiteboard mechanism, but
in a static deployment shouldn't need the whiteboard as we could just
provide a static list of all the available component providers.

BR,

Jukka Zitting