Grouper Users - Open Discussion List

[Kathryn Huxtable <>]

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.
>>>> 
>>> 
>