Felix, Finally got round to doing something about this. I have done a patch at [1] that implements the diagram at the bottom of [2], the Green boxes. At this stage its only in outline, with no test coverage.
I also cleaned up the Service trackers and made then a little bit thread safer. Is this what you were thinking of ? I think it covers my needs, I will probably implement in our custom server bundle. The patch is against the [3] Ian 1 http://codereview.appspot.com/224073 2 http://confluence.sakaiproject.org/display/KERNDOC/KERN-504+Groups+Pull+Integration 3 http://svn.apache.org/repos/asf/jackrabbit/sandbox/jackrabbit2-bundle On 30 Jan 2010, at 10:49, Felix Meschberger wrote: > 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
