Hi, On Mon, Feb 10, 2014 at 1:01 AM, Tobias Bocanegra <tri...@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