hi all i tend to agree with tobi that this might end up with something that is really complicated without too much benefit.
so, we may give it a try but i wouldn't not invest too much time. just my humble opinion... angela On 12/02/14 07:37, "Tobias Bocanegra" <tri...@apache.org> wrote: >Hi, > > >On Tue, Feb 11, 2014 at 4:38 PM, Tobias Bocanegra <tri...@apache.org> >wrote: >> On Tue, Feb 11, 2014 at 1:59 PM, Jukka Zitting >><jukka.zitt...@gmail.com> wrote: >>> On Mon, Feb 10, 2014 at 2:25 AM, Felix Meschberger >>><fmesc...@adobe.com> 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
