On 24 Jan 2010, at 19:08, Felix Meschberger wrote: >> >> >> This structure would work with the providers in bundles and a service >> tracker in the central implementations. The only problem I can see (in my >> naivety) is the Group and User implementations. If the core binds to Impl >> versions then it will be hard to create custom implementations capable of >> answering the membership questions. > > That *is* a problem, though I assume such hard links would rather be > oversight than intent.... So such things will have to be solved.
I am not certain that there a GroupImpl's there but I think I have seen them. Need to check. > > AFAICT internally the Jackrabbit security system works on Prinicipal > instances which are gathered during the authentication process. So any > setup making this more pluggable should theoretically be properly > extensible. Experience will tell .. Actually this brings up another point. I have found, that with external group systems there are "unlisted membership" groups. ie Groups that dont appear on your membership, and don't generate a list of members, but when you ask "is this user a member of this group" the answer might be yes. The reasoning for this is usually driven by 2 senarios. 1) The membership is very large and so rather than being listed, its driven by attributes associated with the user. 2) Membership is time and context driven, ie you are a member of the "taking the exam group" when in the exam hall, when the exam is in progress. Currently the Jackrabbit ACLProviders resolve all principals on session start up, without session caching, 2 is Ok, but to resolve 1 the PrincipalProvider would have to test all known groups this type. If the ACLProvider was able to resolve membership of a Group Principal when the ACE was tested for compilation, then this sort of group would be possible. We have a patch in Sakai to do this which could be simplified a little and follow a similar pattern in the bundleised jackrabbit core. WDYT? Ian
