Hi,
On Tue, Feb 11, 2014 at 4:38 PM, Tobias Bocanegra <[email protected]> wrote: > On Tue, Feb 11, 2014 at 1:59 PM, Jukka Zitting <[email protected]> > wrote: >> On Mon, Feb 10, 2014 at 2:25 AM, Felix Meschberger <[email protected]> >> wrote: >>> This thread indeed raises the question, why Oak has to come up with >>> something (the Whiteboard) >>> that is almost but not quite like OSGi instead of going all the way through >>> ? >> >> This is a misunderstanding; we're not trying to reinvent OSGi. >> >> The Whiteboard interface is *only* an abstraction of the whiteboard >> pattern described in >> http://www.osgi.org/wiki/uploads/Links/whiteboard.pdf, and is used >> only for those cases in Oak where that pattern is useful. When running >> in an OSGi environment, the Whiteboard simply leverages the existing >> OSGi functionality. >> >> The Whiteboard in Oak is not a generic service registry, and is not >> supposed to become one. > but then, why does the Whiteboard interface has a register() method? > This indicates to me, that there is a global service registry behind > that can be used by all other users of the whiteboard. > > Also, using the whiteboard in the tests make them very easy > configurable and simulates a bit better how OSGi will work. for > example in the ExternalLoginModuleTest, I can just do: > > whiteboard = oak.getWhiteboard(); > whiteboard.register(SyncManager.class, new > SyncManagerImpl(whiteboard), Collections.emptyMap()); > whiteboard.register(ExternalIdentityProviderManager.class, new > ExternalIDPManagerImpl(whiteboard), Collections.emptyMap()); > > If I need to register them with the login module, this would not work > today, without hard wiring all possible services to the > SecurityProvider. addendum: If I want to achieve the same without the whiteboard, I would need to: * Invent a new interface that allows to pass services/helpers to the login modules. eg a LoginModuleService interface * Create some sort of LoginModuleServiceProviderConfiguration * Create an implementation of the above that deals with OSGi but also can be used statically * Add the LoginModuleServiceProviderConfiguration to ServiceProvider.getConfiguration() * Add the interface to my ExternalIDPManagerImpl and SyncManagerImpl * in the login module, retrieve the LoginModuleServiceProviderConfiguration from the SecurityProvider, then find a service for SyncManager and ExternalIdentityProviderManager * in the non-osgi case, I would need to initialize the LoginModuleServiceProviderConfigurationImpl myself and add the 2 services and add the config to the securityprovider. The additional work is that I need to re-invent some sort of service registry for the LoginModuleServiceProviderConfigurationImpl and extend the SecurityProvider with another configuration. Also, I limit the interfaces to be used in the LoginModules to the ones implementing the LoginModuleService interface. you might say, this is more robust - I say, this is just more complicated and has tighter coupling. regards, toby
