[Building Sakai] GroupProvider and CourseManagementService too tightly coupled?
Bristow, Paul
PBristow at csu.edu.au
Sun Nov 29 15:36:15 PST 2009
Aaron, Maarten,
I may have had an issue with site info not listing group memberships unless they were associated with a section which I think I fixed in siteinfo.java. But I don't think this broke sakai, it just didn't provide this functionality until I fixed it.
It looks like the main issue I had was (quoting my 2008 emails):
The change to org.sakaiproject.authz.tool.RealmsAction.java to fix SAK-9996 in january 2008 added:
String[] providers = groupProvider.unpackId(provider);
for (int i = 0; i<providers.length; i++)
{
try
{
cms.getSection(providers[i]);
}
catch (IdNotFoundException e)
{
addAlert(state, rb.getString("realm.noProviderIdFound") + " " + rb.getString("realm.edit.provider") + providers[i] + ". ");
}
}
----------------------------------------------------
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
----------------------------------------------------
> -----Original Message-----
> From: azeckoski at gmail.com [mailto:azeckoski at gmail.com] On Behalf Of
> Aaron Zeckoski
> Sent: Monday, 30 November 2009 10:27 AM
> To: Bristow, Paul
> Cc: Maarten van Hoof; Sakai Dev
> Subject: Re: [Building Sakai] GroupProvider and CourseManagementService
> too tightly coupled?
>
> > 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
More information about the sakai-dev
mailing list