Grouper Users - Open Discussion List

[Kathryn Huxtable <>]

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.
> >
> > -K
> >
> >
> > 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
> > > > > > > or
> > > > > > > Signet.
> > > > > > >             
> > > > > > >  
> > > > > >  
> > > > > > 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?
> > > > > > > We
> > > > > > > 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.
> > > > > >
> > > > > >           
> > > > > >  
> > > > >  
> > > >  
> > >  
> >  
> >
> >
> >
> >
> >