Skip to Content.
Sympa Menu

grouper-dev - Problem Paging A Stem Containing Child Groups (start parameter)

Subject: Grouper Developers Forum

List archive

Problem Paging A Stem Containing Child Groups (start parameter)

Chronological Thread 
  • From: Colin Hudler <>
  • To:
  • Subject: Problem Paging A Stem Containing Child Groups (start parameter)
  • Date: Fri, 30 Apr 2010 13:51:58 -0500


In the standard grouper user interface (1.5.2), when a stem contains many groups (more than the page size), clicking next does not advance the page. Instead, it loads the same first page of groups. It was soon discovered that manually setting the "start" parameter to a much higher value, like


Actually did take the user to the next page. I went looking, and I found a likely source of the problem. Please advise if you prefer some other troubleshooting (it is easily reproducible). Skip to the very end for my conclusion.

Ultimately, the stem browsing ui calls

edu.internet2.middleware.grouper.uiAbstractRepositoryBrowser#getChildren(java.lang.String, int, int, java.lang.StringBuffer, boolean, boolean)

defined as

public Set getChildren(String node,String listField,int start,int pageSize,
StringBuffer totalCount,boolean isFlat,boolean isForAssignment,
String omitForAssignment,String context,HttpServletRequest request) throws Exception{

There's a bunch of logic, which in this case comes down to

List<GroupAsMap> listOfMaps = getChildrenAsMaps(s, stemName,
(start/pageSize)+1, pageSize, resultSizeArray);

Note that it takes the "start" and divides it by page size to get the current page.

getChildrenAsMaps() calls another getChildren with a different arity in the same file. It is defined as

public List<GroupOrStem> getChildren(GrouperSession s, String stemId,
int start, int pageSize, int[] resultSize) throws StemNotFoundException{

Here it finally starts to get the children, and uses paging in a conditional block:

QueryOptions queryOptions = null;
if (this.pagedQuery()) {
QueryPaging queryPaging = null;
queryPaging = new QueryPaging();
queryOptions = new QueryOptions().paging(queryPaging);
children=getChildGroups(stem, queryOptions);
if (GrouperUtil.length(resultSize) >= 1) {
if (this.pagedQuery()) {
resultSize[0] = queryOptions.getCount().intValue();

It is calling "queryPaging.setFirstIndexOnPage(start);" with the start parameter converted already by the other getChildren(). Let's take a look at what edu.internet2.middleware.grouper.internal.dao.QueryPaging#setFirstIndexOnPage does with it:

this.pageNumber = (startIndex / pageSize) + 1;

HMMM, looks like it will always be "1" unless our "start" parameter is one extra pageSize magnitude larger. I hope you enjoyed this journey, and I hope the problem is clear.

It appears that the start parameter should not be converted into a page number by getChildren. I haven't bothered to examine the consequences of changing edu.internet2.middleware.grouper.uiAbstractRepositoryBrowser#getChildren

Let me know if I can clarify further, or it is completely wrong direction!

  • Problem Paging A Stem Containing Child Groups (start parameter), Colin Hudler, 04/30/2010

Archive powered by MHonArc 2.6.16.

Top of Page