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:31:57 GMT

On Tue, Feb 11, 2014 at 11:56 PM, Chetan Mehrotra
<chetan.mehrotra@gmail.com> wrote:
> To address the same problem with Felix Jaas support one can make use
> of LoginModuleFactory [1]. Its job is to create LoginModule instances.
> One example of this is JdbcLoginModuleFactory [2]. It creates
> JdbcLoginModule and passes on the DataSource to the LoginModule
> instances. So instead of LoginModule _looking up_ the DataSource
> service it is provided with the DataSource instance. The factory
> itself was _provided_ with DataSource reference via DI (via
> Declarative Services)
> To implement a similar approach in non OSGi world following approach can be used
> 1. Have a ProxyLoginModule like [3]. The JAAS Config would refer to
> this class and would be able to create it
> 2. Have a LoginModuleFactory LMF (custom one) which is referred to in
> the JAAS Config.
> 3. One can register a custom LMF implementation with Oak and they
> would be passed on to SecurityProvider
> 3. ProxyLoginModule determines the type of LoginModuleFactory and
> obtains them via Callback
> 4. The LMF obtained is used to create the LoginModule instance
> Now same LoginModule (where most of the logic reside) can be shared
> between OSGi and non OSGi world. Further you can even share the
> LoginModuleFactory (if using non OSGi stuff only).
> For OSGi case the LMF would be managed via DS and its dependencies
> provided via DS
> For non OSGi case host application would wire up the LMF with its
> dependencies (via setters) and then register them with the Oak

Interesting idea, but I think we should continue support the LM to be
configured via the application container (eg. via jaas.conf).
Regards, Toby

> Chetan Mehrotra
> [1] http://svn.apache.org/repos/asf/felix/trunk/jaas/src/main/java/org/apache/felix/jaas/LoginModuleFactory.java
> [2] http://svn.apache.org/repos/asf/felix/trunk/examples/jaas/lm-jdbc/src/main/java/org/apache/felix/example/jaas/jdbc/JdbcLoginModuleFactory.java
> [3] http://svn.apache.org/repos/asf/felix/trunk/jaas/src/main/java/org/apache/felix/jaas/boot/ProxyLoginModule.java
> On Wed, Feb 12, 2014 at 12:07 PM, 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>
>>>> On Mon, Feb 10, 2014 at 2:25 AM, Felix Meschberger <fmeschbe@adobe.com>
>>>>> 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

View raw message