jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angela Schreiber <anch...@adobe.com>
Subject Re: Make "Whiteboard" accessible through ContentRepository
Date Wed, 12 Feb 2014 16:07:20 GMT
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" <tripod@apache.org> wrote:

>Hi,
>
>
>On Tue, Feb 11, 2014 at 4:38 PM, Tobias Bocanegra <tripod@apache.org>
>wrote:
>> On Tue, Feb 11, 2014 at 1:59 PM, Jukka Zitting
>><jukka.zitting@gmail.com> wrote:
>>> On Mon, Feb 10, 2014 at 2:25 AM, Felix Meschberger
>>><fmeschbe@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


Mime
View raw message