Hi, Yes, the current LoginModulePlugin interface we have is conceptually incomplete. For my prototype of migrating that stuff to Jackrabbit, I have added a LoginModulePluginFactory service interface, which creates LoginModule instances on demand, which are then used for a single login process only.
See also http://wiki.apache.org/jackrabbit/JackrabbitOsgi Regards Felix On 29.01.2010 18:50, Ian Boston wrote: > Hi, > > IIRC, LoginModules are bound to a session, hence one is created with the > session to service its needs, and then destroyed when the session is > destroyed. On creation the doInit(CallbackHandler callbackHandler, Session > session, Map options) with the session that the LoginModule is bound to. > > With the Sling PluggableLoginModule this happens, but then there is an > Activator.getLoginModules() (a static), which goes to the activator and grabs > the list of LoginModulePlugins from the service tracker. AFAICT, these are > singleton service implementations. > > Next doInit() is called on each module. > > later setPrincipal(Set ) is called on each module. > > IIUC that means that all LoginModulePlugin implementations must bind their > state to the thread making the method call, since they are a service and not > created new with each session. They must also be thread safe, and we are > assuming (probably safely) that only a single thread will ever use the > session in question. AFAICT, there is no other way of sharing state on calls > like setPrincipal(Set). > > Did I read the code correctly ? > Was this the intention or were LoginModulePlugins intended to be created with > the session and bound to the session ? > > Ian
