Skip to Content.
Sympa Menu

grouper-users - Re: [grouper-users] grouper loader - group lists and target stems

Subject: Grouper Users - Open Discussion List

List archive

Re: [grouper-users] grouper loader - group lists and target stems


Chronological Thread 
  • From: Rob Gorrell <>
  • To: Chris Hyzer <>
  • Cc: "" <>
  • Subject: Re: [grouper-users] grouper loader - group lists and target stems
  • Date: Wed, 3 Sep 2014 14:28:51 -0400

yes I do... still working to get 2.1.3 off the ground before distracting myself with an upgrade. I'll look into that, thanks!

-Rob



On Wed, Sep 3, 2014 at 2:26 PM, Chris Hyzer <> wrote:

Do you have less than 2.1.4 (or maybe 2.1.5)?  Can you patch this file and make it work?

 

https://bugs.internet2.edu/jira/browse/GRP-913

 

grouper loader ldap loader.ldap.requireTopStemAsStemFromConfigGroup put an extra colon at front of name and hence doesnt work

 

Note, for list of groups, this is fixed in 2.1.4, for groups from attributes, it is fixed in 2.1.5. It is a very small tweak in GrouperLoaderresultSet.java (two places): 

FROM: 
    if (!groupParentFolderNameTemp.endsWith(":")) { 

TO: 
    if (!StringUtils.isBlank(groupParentFolderNameTemp) && !groupParentFolderNameTemp.endsWith(":")) { 

 

Thanks,

Chris

 

 

From: [mailto:] On Behalf Of Rob Gorrell
Sent: Wednesday, September 03, 2014 2:10 PM
To: Chris Hyzer
Cc:
Subject: Re: [grouper-users] grouper loader - group lists and target stems

 

Sorry to dredge up an old thread, but I'm trying revisit targeting an LDAP_GROUP_LIST to a stem location that isn't under the branch of the loader object thats loading it...
I've set the metadata grouperLoaderLdapGroupNameExpression = "uncg:orgs:${groupAttributes['cn']}" and loader.ldap.requireTopStemAsStemFromConfigGroup = false as you instructed me before.
but now all I get from running the loader job is...

edu.internet2.middleware.grouper.exception.StemNotFoundException: Can't find stem by name: ':uncg:orgs',
Problem in HibernateSession: HibernateSession: isNew: true, isReadonly: false, grouperTransactionType: READ_WRITE_NEW


I assure you that stem exists... i've even checked it against the GROUPER_STEMS table in grouper's database, no typo's, the stem thats reported in the loader error should be a valid stem.

Is there something I'm missing/not getting after setting loader.ldap.requireTopStemAsStemFromConfigGroup = false? It works fine when I set this back to true, just the groups are created under a branch I don't desire them to be.

Thanks
-Rob

 



 

On Tue, Aug 20, 2013 at 2:38 PM, Chris Hyzer <> wrote:

Yeah, set this in the grouper-loader.properties:

 

# by default the top folder for an ldap group of groups is the folder where the config group lives.

# set to false if you want to be able to provision groups to anywhere

loader.ldap.requireTopStemAsStemFromConfigGroup = true

 

 

Note, it is a global setting, so if you have existing jobs, you will have to change those configs so they are absolute in the right spot…

 

Also, there were some Jira’s about this which I believe are all resolved in 2.1.4

 

Thanks,

Chris

 

From: [mailto:] On Behalf Of Rob Gorrell
Sent: Tuesday, August 20, 2013 2:15 PM
To:
Subject: [grouper-users] grouper loader - group lists and target stems

 

So i've been playing with the LDAP_GROUP_LIST and SQL_GROUP_LIST loader types and noticed a difference related to the ability to target where (what stem) we load the new groups. In the sql group list, I'm able to have my loader object located in one stem (say loader:orgGroup) and load groups into another adjecent stem (say orgs:) where the loader object isn't located and this works. However, if I try to do the same with the ldap group list by defining a 'LDAP group name _expression_" metadata element (say also orgs:${groupAttributes['cn']}), this path becomes appended to the path of the loader object and creates the groups in :loader:orgs instead of :orgs like the sql group list does.

 

Is there a way to make the ldap group list create an object relative to the root stem instead of its parent loader object?

 

-Rob



--

Robert W. Gorrell
Middleware Engineer, Identity and Access Management

University of NC at Greensboro
336-334-5954




--

Robert W. Gorrell
Systems Architect, Identity and Access Management

University of NC at Greensboro
336-334-5954
PGP Key ID B36DB0CA




--
Robert W. Gorrell
Systems Architect, Identity and Access Management
University of NC at Greensboro
336-334-5954
PGP Key ID B36DB0CA



Archive powered by MHonArc 2.6.16.

Top of Page