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 Tue, 11 Feb 2014 16:59:08 GMT
Hi,

On Tue, Feb 11, 2014 at 1:14 AM, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> On Mon, Feb 10, 2014 at 8:35 PM, Tobias Bocanegra <tripod@apache.org> wrote:
>> I'd rather offer it via a Callback.
>
> Callbacks are not really meant for such use. Their purpose is to allow
> the authentication component to "interact with the application to
> retrieve specific authentication data, such as usernames and
> passwords, or to display certain information, such as error and
> warning messages", not to access the rest of the runtime environment.
>
> What we should do instead is to pass context information via the
> options map passed to LoginModule.initialize() method.
Right, this might be better :-) I just followed the pattern already
there with all the other callbacks :-)

> For example the
> Karaf JAAS implementation passes the BundleContext through the options
> map. The LoginModule class would then look into the options map for
> any dependencies it has. Something like this:
>
>     abstract class MyLoginModule implements LoginModule {
>
>         private LoginBackend backend;
>
>         protected abstract LoginBackend getLoginBackend(Map<String, ?> options);
>
>         @Override
>         public initialize(...,Map<String,?> options) {
>             this.backend = getLoginBackend(options);
>         }
>
>     }
>
> Subclasses can specialize the lookup method to work with different
> runtime environments. For example in an OSGi/Karaf environment this
> could be (omitting error handling and details like handling of service
> reference counts):
>
>     class MyOsgiLoginModule extends MyLoginModule {
>         @Override
>         protected LoginBackend getLoginBackend(Map<String, ?> options) {
>             BundleContext context = (BundleContext)
> options.get(BundleContext.class.getName());
>             return getLoginBackend(context); // OSGi service lookup
>         }
>     }
>
> Or in a plain old Java environment:
>
>     class MyJavaLoginModule extends MyLoginModule {
>         @Override
>         protected LoginBackend getLoginBackend(Map<String, ?> options) {
>             return (LoginBackend) options.get(LoginBackend.class.getName());
>         }
>     }
>
> ... with the following bootstrapping code:
>
>     LoginBackend backend = new LoginBackend(...);
>     Map<String, ?> options =
> singletonMap(LoginBackend.class.getName(), backend);
>     Configuration.setConfiguration(new
> ConfigurationExtender(Configuration.getConfiguration(), options));
>
> (The ConfigurationExtender class would decorate the given default
> configuration with the given extra options.)
>
> Note how none of this requires a dependency to the Whiteboard. We of
> course *can* depend on the Whiteboard if the login code needs stuff
> like dynamic service registration or lookups, but there's no inherent
> need for that dependency.

True, but if we want to write LoginModules what work in both worlds,
then we need to offer a common interface to access to services - and
that's currently the whiteboard.

Regards, Toby

Mime
View raw message