jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tobias Bocanegra <tri...@apache.org>
Subject Re: Make "Whiteboard" accessible through ContentRepository
Date Wed, 12 Feb 2014 15:15:13 GMT
Hi,

On Wed, Feb 12, 2014 at 2:00 AM, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> On Wed, Feb 12, 2014 at 1:37 AM, Tobias Bocanegra <tripod@apache.org> wrote:
>> On Tue, Feb 11, 2014 at 4:38 PM, Tobias Bocanegra <tripod@apache.org> 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

Mime
View raw message