Hi, On Wed, Feb 12, 2014 at 2:00 AM, Jukka Zitting <[email protected]> wrote: > On Wed, Feb 12, 2014 at 1:37 AM, Tobias Bocanegra <[email protected]> wrote: >> On Tue, Feb 11, 2014 at 4:38 PM, Tobias Bocanegra <[email protected]> wrote: >>> 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. > > The whiteboard pattern requires mechanisms for registering services > and tracking them. Note that the Whiteboard interface explicitly does > not have a getService() method, only track() method used by event > sources in the whiteboard pattern. > >>> 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: > > This seems too complicated. Why not just pass the dependencies > directly to the LoginModule component, using the pattern I suggested > earlier? > >> addendum: If I want to achieve the same without the whiteboard, I would need >> to: > > This also seems too complicated. > >> 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. > > Not more robust, just way too complicated. :-) > > I don't see why stuff like LoginModuleServiceProviderConfigurationImpl > or even SecurityProvider would need to be involved here. Just pass > the required dependencies directly to the LoginModule implementation > and forget the rest of the stack. There should be no need to route > those dependencies through multiple layers of provider/configuration > objects. The way I see it, the perceived need for a service registry > is just a side-effect of trying to force things to such a pattern. > > This is all the wiring that we should need for Java-only environments: > > LoginBackend backend = > new LoginBackend(dependency1, dependency2, ...); > Map<String, ?> options = singletonMap( > LoginBackend.class.getName(), backend); > Configuration.setConfiguration(new ConfigurationExtender( > Configuration.getConfiguration(), options)); > > Or in the OSGi case, make LoginBackend a service and use something > like the LoginModuleFactory Chetan mentioned.
But this LoginBackend is in the end something similar like a specialized ServiceRegistry. So why not use the whiteboard instead? However, I give it a try refactoring it with a LoginBackend - even if only to avoid the callbacks. regards, toby
