Hi, On Sun, Feb 9, 2014 at 9:40 AM, Jukka Zitting <jukka.zitt...@gmail.com> wrote: > Hi, > > On Sat, Feb 8, 2014 at 1:58 PM, Tobias Bocanegra <tri...@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
