[Contrib: Evaluation System] provider not being called

Jim Eng jimeng at umich.edu
Tue Sep 28 09:16:02 PDT 2010


That will be a problem if it works that way.  We will need to get updates about once a day, especially early in a semester.  Updates will need to add and remove people from groups.  I would be surprised if there is not support for that.  

Jim


On Sep 28, 2010, at 11:59 AM, Richard C. Moyer II wrote:

> The evaluation takes a snapshot of the data when it is created.  Only those students enrolled at the time the evaluation is built are included.
> 
> Likewise a student who drops or withdraws are still included in the evaluation.
> 
> Rick
> 
> -----Original Message-----
> From: evaluation-bounces at collab.sakaiproject.org [mailto:evaluation-bounces at collab.sakaiproject.org] On Behalf Of Charles Hedrick
> Sent: Tuesday, September 28, 2010 11:43 AM
> To: Aaron Zeckoski
> Cc: evaluation at collab.sakaiproject.org
> Subject: Re: [Contrib: Evaluation System] provider not being called
> 
> What happens if a student adds a course after the evals are set up?
> 
> On Sep 28, 2010, at 10:02 AM, Aaron Zeckoski wrote:
> 
>> Jim,
>> That is correct. The group provider is only consulted when setting up 
>> the evals or updating them. Otherwise, the internal DB groups records 
>> are used. This was done to remove the bottlenecks and performance 
>> issues related to providers which were not written as efficiently. It 
>> also simplified a lot of the logic by removing complex merges of data 
>> from various sources.
>> 
>> For the rutgers situation, it may be beneficial to examine the groups 
>> tables and see if data is missing. If the groups tables have the data 
>> but the users still are unable to access things then there might be 
>> something wrong.
>> 
>> -AZ
>> 
>> 
>> On Tue, Sep 28, 2010 at 8:40 AM, Jim Eng <jimeng at umich.edu> wrote:
>>> I am following this discussion closely because we are hoping to move 
>>> to a newer version of evalsys.  It seems to me that Aaron Z told us a 
>>> year or so ago that the way the group provider works had changed at some point.
>>> If I recall correctly, in early versions of evalsys, the provider was 
>>> consulted frequently while handling user requests.  In trunk (or 
>>> 1.3.x), I think he said that the group information is stored 
>>> internally and the group provider is consulted occasionally to update 
>>> it.  That was done to streamline queries that matched users with evals by group membership, IIRC.
>>> 
>>> Is this a correct description?  If so, your question might be why the 
>>> group info is not being persisted adequately within sakai, rather 
>>> than why the group provider is not being consulted in handling particular requests.
>>> Jim
>>> 
>>> 
>>> On Sep 28, 2010, at 9:21 AM, Aaron Watters wrote:
>>> 
>>> Hi Richard,
>>> 
>>> I work with Chuck at Rutgers.  I will try to answer your questions 
>>> and Chuck can correct me if he feels the need.
>>> 
>>> On Mon, Sep 27, 2010 at 4:20 PM, Richard C. Moyer II <rmoyer at umd.edu> wrote:
>>>> 
>>>> Charles,
>>>> 
>>>>       Here at Maryland we also use the eval group provider, but 
>>>> unfortunately, I cannot reproduce your error. Currently I'm in the 
>>>> middle of testing evaluation trunk, revision 70243, against our 
>>>> config and providers with the hope of migrating to sakai 2.7.
>>>> 
>>>>       To help trouble shoot your situation, we'll need a little 
>>>> more details.
>>>> 
>>>> 1. 'We're not seeing people in our evaluations' - are you signing on 
>>>> as a student and there are no evaluations or are signing on as an 
>>>> instructor or admin?
>>>> 
>>> 
>>> We tried both.  The students see no evaluations and the admins see 0 
>>> students in the evaluations.
>>> 
>>>> 2. 'Our evaluations come entirely from the Rutgers provider.' - are 
>>>> you building your evaluations outside of the sakai evaluation tool 
>>>> and importing in or are you building the evaluation using this tool 
>>>> and your groups, students, instructors, and TA come from your provider?
>>>> 
>>> 
>>> We import the evaluation data directly into the database.
>>> 
>>>> 
>>>> 3. 'old code' do you have a date or revision number?
>>>> 
>>> I believe it was the 1.2 stable release.
>>> 
>>>> 
>>>> 4. 'new code' do you have a date or revision number?
>>>> 
>>> 
>>> 1.3 RC 2.
>>> 
>>>> 
>>>> 5. what are the results from the Test EvalGroupProvider from the 
>>>> Administrate screen? As an admin, student & groupId.
>>>> Are you getting  back Rutger's IDs or sakai IDs?
>>>> 
>>> 
>>> "Unexpected error" with the following (abbreviated) traceback in 
>>> catalina.out
>>> 
>>> 2010-09-28 09:05:03,200 WARN (RenderHandlerBracketer.java:107) - 
>>> <Exception rendering view: >
>>> java.lang.IllegalArgumentException: Cannot add leaf component with ID 
>>> summary-link of class uk.org.ponder.rsf.components.UIInternalLink as a child
>>> of component with ID   viewroot   of class uk.org.ponder.rsf.view.ViewRoot
>>> since it would displace an existing child of the same name.
>>>   Please remove the existing component first.
>>>        at
>>> uk.org.ponder.rsf.components.UIContainer.addComponent(UIContainer.java:142)
>>>        at
>>> uk.org.ponder.rsf.components.UIInternalLink.make(UIInternalLink.java:40)
>>>        at
>>> org.sakaiproject.evaluation.tool.producers.AdminTestEGProviderProducer.fillComponents(AdminTestEGProviderProducer.java:133)
>>>        at
>>> uk.org.ponder.rsf.view.support.ViewCollector.fillComponents(ViewCollector.java:56)....
>>> 
>>> 
>>>> 
>>>> 6. are you using a UserDirectoryProvider?
>>> 
>>> It doesn't look like it.  Should we be?
>>> The Rutgers interface implements the following signature
>>> 
>>> public class RutgersEvalGroupsProvider implements 
>>> org.sakaiproject.evaluation.providers.EvalGroupsProvider {...}
>>> 
>>>> 
>>>> The summaryProducer, and supporting code has gone through several 
>>>> enhancements and re-writes over the years. It's possible that 
>>>> depending on how old your code is that your caught in a void that has since been fixed.
>>>> 
>>>> Please let us know this info and perhaps we can dig a little deeper 
>>>> into the code.
>>> 
>>> Thanks for your attention.  -- Aaron Watters (aaron at rutgers.edu)
>>> 
>>> _______________________________________________
>>> evaluation mailing list
>>> evaluation at collab.sakaiproject.org
>>> http://collab.sakaiproject.org/mailman/listinfo/evaluation
>>> 
>>> TO UNSUBSCRIBE: send email to 
>>> evaluation-unsubscribe at collab.sakaiproject.org
>>> with a subject of "unsubscribe"
>>> 
>>> _______________________________________________
>>> evaluation mailing list
>>> evaluation at collab.sakaiproject.org
>>> http://collab.sakaiproject.org/mailman/listinfo/evaluation
>>> 
>>> TO UNSUBSCRIBE: send email to 
>>> evaluation-unsubscribe at collab.sakaiproject.org
>>> with a subject of "unsubscribe"
>>> 
>> 
>> 
>> 
>> --
>> Aaron Zeckoski - Software Engineer - http://tinyurl.com/azprofile 
>> _______________________________________________
>> evaluation mailing list
>> evaluation at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/evaluation
>> 
>> TO UNSUBSCRIBE: send email to evaluation-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
> 
> _______________________________________________
> evaluation mailing list
> evaluation at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/evaluation
> 
> TO UNSUBSCRIBE: send email to evaluation-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
> 
> 



More information about the evaluation mailing list