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. 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? > 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. > 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? > 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. BR, Jukka Zitting