[Building Sakai] GroupProvider and CourseManagementService too tightly coupled?

Sun Nov 29 15:26:41 PST 2009

> IMHO the group provider should not assume use of course management or
>  section dependencies. I think you will need to change sakai code to fix
> this.

I definitely agree. If that is truly the case you should probably
raise a JIRA against the group provider. It should not have
dependencies (strong ones anyway) on CM.
-AZ


On Sun, Nov 29, 2009 at 11:15 PM, Bristow, Paul <PBristow at csu.edu.au> wrote:
> Maarten,
>
>
>
> I think I had the same issue. Some CMS dependencies seem to have been
> created which assume that you will only use the group provider if you use
> the CMS. I think I got around it by reversing the changes that put these in
> but we’re only using 2.4.x so your mileage may vary.
>
>
>
> IMHO the group provider should not assume use of course management or
>  section dependencies. I think you will need to change sakai code to fix
> this.
>
>
>
> ----------------------------------------------------
> Paul Bristow
> Applications Architect
> Division of Information Technology
> Charles Sturt University
> Ph: 02 6051 9959
> Fax: 02 6051 9919
> pbristow at csu.edu.au
> www.csu.edu.au
> ----------------------------------------------------
>
> YOU MUST READ THIS NOTICE
>
> This email has been sent by Charles Sturt University (ABN 83 878 708 551).
> This email
> (and any attachment) is confidential and is intended for the use of the
> addressee(s)
> only. If you are not the intended recipient of this email you must not copy,
> distribute, take any action in reliance on it or disclose it to anyone. Any
> confidentiality is not waived or lost by reason of mistaken delivery to you.
> The
> views expressed in this email are not necessarily those of Charles Sturt
> University.
> It is very important that before opening any attachments to this email you
> check them
> for viruses and defects. CSU does not accept liability for any corruption or
> viruses
> or any consequence which arise as a result of this email transmission. Email
> communications with CSU may be subject to automated email filtering, which
> could result
> in the delay or deletion of a legitimate email before it is read by its
> intended
> recipient at CSU. Please tell us if you have concerns about this automatic
> filtering.
> The Commonwealth Register of Institutions and Courses for Overseas Students
> (CRICOS)
> Provider Number is 00005F (NSW), 025973E (QLD), and 01947G (VIC) for Charles
> Sturt
> University.
> ----------------------------------------------------
>
> From: sakai-dev-bounces at collab.sakaiproject.org
> [mailto:sakai-dev-bounces at collab.sakaiproject.org] On Behalf Of Maarten van
> Hoof
> Sent: Friday, 27 November 2009 8:20 PM
> To: Sakai Dev
> Subject: [Building Sakai] GroupProvider and CourseManagementService too
> tightly coupled?
>
>
>
> 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
>
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org
> with a subject of "unsubscribe"
>


-- 
Aaron Zeckoski (azeckoski (at) vt.edu)
Senior Research Engineer - CARET - University of Cambridge
https://twitter.com/azeckoski - http://www.linkedin.com/in/azeckoski
http://aaronz-sakai.blogspot.com/ - http://tinyurl.com/azprofile