Skip to Content.
Sympa Menu

grouper-users - Re: [grouper-users] oops with Ldappc v1.0

Subject: Grouper Users - Open Discussion List

List archive

Re: [grouper-users] oops with Ldappc v1.0

Chronological Thread 
  • From: Kathryn Huxtable <>
  • To: Gil Singer <>, Grouper Users <>
  • Subject: Re: [grouper-users] oops with Ldappc v1.0
  • Date: Sat, 20 Jan 2007 21:53:41 -0600

Title: Re: [grouper-users] oops with Ldappc v1.0
To amplify, the ldappc.xml file in the classpath can be empty if the –configManager option is used, but it must exist. -K

On 1/20/07 8:15 PM, "Gil Singer" <> wrote:

With respect to whether the -configManager switch work in the Ldappc program, the answer is "yes".  However, the documentation needs to be modified to alert the user to a couple of potential pitfalls.  First, when specifying the value for the -configManager, use a file name and do not use a prefix like "file:///" <file:///> .

Second, Jeff VanEeuwen and Kathryn Huxtable determined the following Ldappc behavior, as described by Jeff as follows.  "By default, Ldappc searches the class path for the ldappc.xml configuration file.  This behavior can be overridden by the -configManager option.  The -configManager option causes Ldappc to use the configuration file identified by -configManager rather than the file found in the class path.  However, even though Ldappc uses the file identified by -configManager, Ldappc still expects to find a default ldappc.xml file in the class path.  If this default ldappc.xml file is not found in the class path, an exception is thrown by Ldappc.  In order to avoid this issue, an ldappc.xml file must be included in the class path even if the -configManager option is used."

-- Gil Singer

Kathryn Huxtable wrote:

Is there any evidence that the -configManager switch actually works? I only
see the code searching the CLASSPATH for a resource and loading it.


On 1/15/07 3:09 PM, "Kathryn Huxtable" <>  wrote:


That's what I wanted. Thanks! -K

On 1/15/07 11:56 AM, "Tom Barton" <>  wrote:


Right. Ldappc persists nothing on its own behalfand changes nothing in
grouper or signet database. You should be able to provision more than
one target with multiple Ldappc instances, the only proviso being that
one Ldappc instance must "own" its target, where "target" is the
conjunction of ldap server, DIT area, and ldap schema declared in an
Ldappc XML config file. So, you can also have multiple Ldappc instances
provisioning to different areas within one directory.

Kathryn Huxtable wrote:

So there's no action queue or anything like that that would prevent two
copies provisioning groups to two different LDAP directories... -K

On 1/15/07 8:34 AM, "Tom Barton" <>  wrote:


<taking this to just the grouper-users list>

Kathryn Huxtable wrote:

1) can we run multiple copies of ldappc to provision two separate
directories, e.g. a SunJava directory server for most uses and an Active
Directory server for our Exchange distribution lists? Will they collide in
any way?

I guess I'm asking how ldappc knows that a change has occurred in Grouper

Ldappc essentially computes a logical diff between the groups,
memberships, and permissions selected from the grouper and signet
databases and those that are in the configured schema and DIT areas in
the target directory. It makes no change whatsoever to the grouper or
signet databases.


2) Are there any plans for a JDBC source connector configuration in this?
don't generally use JNDI for our sources. We *can*, but I'm not sure why
we'd want to.

No. We focused specifically on ldap since that covers the largest number
of potential deployments.

The ldappc code might give you a leg up, though, on building a
provisioning connector for some other target technology. It's
architected with pieces that face grouper & signet and separate pieces
that face the target. You might be able to reuse the former and the
overall application architecture.



Archive powered by MHonArc 2.6.16.

Top of Page