[Building Sakai] GroupProvider and CourseManagementService too tightly coupled?

Maarten van Hoof maarten.vanhoof at gmail.com
Fri Nov 27 01:19:37 PST 2009


Hi all,

I'm sorry for spamming this list twice with the same question, but I'm
really hoping to get an answer.

Either I don't understand how GroupProvider and CourseManagementService
work, or there are some flaws in how they are implemented in Sakai. The way
I understand it, you can implement your own GroupProvider and that
implementation needs no knowledge of how the CourseManagementService is
implemented. Is that right?

I have developed an implementation of GroupProvider that manages a form of
delegated administration: it gives certain users maintain access to a
predefined set of sites. The users in question are members of a 'delegated'
administration workspace and the set of sites is defined inside that
workspace. It works like this: each of the 'managed' sites gets a
groupProviderId that is equal to the site id of the delegated administration
workspace. When called, my GroupProvider looks up the admin site and gives
all members of that site maintain access to the managed site. It works quite
well, but I've run into two problems. Please bear with me.


1. In the realms tool, when I set the groupProviderId of a managed site
manually (which I wouldn't normally do, but still) I am told that the
provider id is invalid. That is because in RealmsAction.java, in the method
readRealmForm, the providerId is checked with the CourseManagementService
(cms.getSection). I do not understand why this happens. I think it assumes a
particular implementation of courseManagementService.

I think I solved this correctly by creating a federated course management
service (org.sakaiproject.
coursemanagement.impl.CourseManagementServiceFederatedImpl) that first calls
the default course management service and then calls a
CourseManagementService of my own design. The latter is a
CourseManagementServiceSampleChainImpl which only overwrites the getSection
method. The implementation simply checks if the given groupProviderId is
valid and if it is, it returns null.

This solves the problem I have with the realms tool, but introduces a new
problem.

2. When I place a roster tool on a managed site, it will display a
nullpointer exception. I traced that back to
org.sakaiproject.tool.roster.StatusRequestCache.init(), which, again, checks
the site's groupProviderId with the course management service. In this
instance, it iterates over the sections that the cms returns and gets the
enrollment sets. But because I solved 1 by returning null (rather than
throwing an IdNotFoundException), section.getEnrollmentSets throws a
nullpointer.


Thank you for bearing with me.

I have two questions:
- Why does the code assume that a group provider id be linked to a section?
Does that not assume a particular implementation of both the group provider
and the course management service?
- Is there any way I can solve this without changing Sakai code? If there
isn't, am I correct in assuming that I should change the code in
RealmsAction? I think the roster tool gets it right: it will ignore an
IdNotFoundException.

Thanks,
Maarten van Hoof
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20091127/90e90824/attachment.html 


More information about the sakai-dev mailing list