Hi, On Mon, Feb 10, 2014 at 1:30 PM, Jukka Zitting <[email protected]> wrote: > On Mon, Feb 10, 2014 at 2:50 PM, Tobias Bocanegra <[email protected]> wrote: >> in case of the LoginModules, that's not possible. > > But accessing the whiteboard is? I don't see what's special about the > whiteboard, it's just a service dependency like any other.
No, it's a piece of infrastructure, and part of the Oak SPI. I think that components should be able to rely on a system wide Whiteboard if they want. Also, the LoginModules are not 'services' in that sense. they get instantiated by JAAS and can only communicate via Callbacks with the login context. >> 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. > > That is OK, at least that's been the plan so far. It doesn't make > sense for Oak to reinvent a component framework like OSGi or Spring. > Instead Oak components should be usable within any such framework, or > even in plain old Java. > >> 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. > > Right. I guess we should refactor that part of the code to avoid the > overrides. ok: https://issues.apache.org/jira/browse/OAK-1411 regards, toby
