jackrabbit-oak-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chetan Mehrotra <chetan.mehro...@gmail.com>
Subject Re: Make "Whiteboard" accessible through ContentRepository
Date Wed, 12 Feb 2014 07:56:33 GMT
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

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> wrote:
>>> 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