jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jukka Zitting <jukka.zitt...@gmail.com>
Subject Re: Make "Whiteboard" accessible through ContentRepository
Date Wed, 12 Feb 2014 10:00:52 GMT

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

> 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.


Jukka Zitting

View raw message