[Building Sakai] GroupProvider and CourseManagementService too tightly coupled?
Maarten van Hoof
maarten.vanhoof at gmail.com
Mon Nov 30 04:54:17 PST 2009
Thanks all. I hadn't found http://jira.sakaiproject.org/browse/SAK-17414 and
didn't realize that that was the faulty code (I did locate the code that you
sent, Paul), so I tried to work around it, which introduced my other
troubles. So if I ditch my workaround and apply the patch for SAK-17414 I
think I'll be alright.
Thanks,
Maarten
2009/11/30 Bristow, Paul <PBristow at csu.edu.au>
> 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
>
--
Geniet, maar drink met Maarten
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20091130/c5c587ee/attachment.html
More information about the sakai-dev
mailing list