Hi,
On Mon, Feb 10, 2014 at 4:31 AM, Jukka Zitting <jukka.zitt...@gmail.com> wrote: > 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. in case of the LoginModules, that's not possible. They need to retrieve their services from somewhere. > 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. This is ok for unit tests etc, but there is currently no way of "configuring" Oak. So there is no ootb "run.sh" that will start your oak server. If we ever want to go there, we need to define how to get there. We can shift this problem to Sling and let them provide such a server, or we can start your own "launchpad". currently, you need to compile classes in order to configure your server. if this is ok, we can stay with the current setup and hard-wire all dependencies. > > 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. If you want to make this work generally w/o OSGi, then you also need to invent a DS management for oak...which is clearly not a goal. > > 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? got me :-) I overlooked that. > > 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. The problem is, that the whiteboard that is initially initialized in Oak() already has some anonymous overrides for delaying stuff. So when passing a non-osgi one externally, this logic is lost, although it might be needed. > 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. well :-) regards, toby
