Skip to Content.
Sympa Menu

grouper-dev - [grouper-dev] [ldappcng] incremental provisioning : find ChangeLogEntry by id ?

Subject: Grouper Developers Forum

List archive

[grouper-dev] [ldappcng] incremental provisioning : find ChangeLogEntry by id ?

Chronological Thread 
  • From: Tom Zeller <>
  • To: Grouper Dev <>
  • Subject: [grouper-dev] [ldappcng] incremental provisioning : find ChangeLogEntry by id ?
  • Date: Thu, 28 Apr 2011 22:00:42 -0500
  • Domainkey-signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; b=h9yPJtCKM+P2kcQo02yw61mmkDTFqgEnBRVJIQjc/T01aMbEQa9xwm538cFS+tblE4 VKpVCm1DD4XEJubhC26/TLrVeDTyUH+QLcc09tLlZMhx7aFy4LG4WDCpU3g03E5AxWAw EuMRsL5WiBoKOi2cdQBYKo7lc9LSVF4R3wJH8=

Could it be possible to retrieve a ChangeLogEntry by string id ? while
the changeLogEntry is being processed by a ChangeLogConsumer ?

e.g. ChangeLogEntry ChangeLogEntryFinder.findById(String changeLogEntryId);

Details below :

The idea is to represent memberships as distinct objects in the
ldappcng configuration :

<object id="group" ... />

<object id="member" ... />

// NEW : distinct membership object
<object id="group-membership">
<identifier ... />
<references name="member" >
<reference toObject="member" ... />

This distinct membership object would be calculated when the
Shibboleth AttributeResolver processes an attribute query whose
identifier is the id of a ChangeLogEntry, e.g. changeLogEntry.getId().
A ChangeLogDataConnector would return attributes appropriate for the
type of ChangeLogEntry. For example, when processing a membership_add
or membership_delete changelog entry, it would query for the Group and
Member by their ids.

Again, the ChangeLogDataConnector would need to query for a
ChangeLogEntry by id, hence the original question.

So, ldappcng, acting as a ChangeLogConsumer, would calculate the
distinct membership objects based on the id of a changelog entry :

public long processChangeLogEntries(List<ChangeLogEntry>
changeLogEntryList ...) {
CalcRequest calcRequest = new CalcRequest();
CalcResponse calcResponse = psp.execute(calcRequest);

The result of the AttributeResolver calculation (the CalcResponse)
will be an SPML PSO (provisioned service object) similar to :

<ldappc:pso entityName='group'>
<psoID ID='cn=groupB,ou=testgroups,${base}' targetID='ldap'/>
<spmlref:reference typeOfReference='member'>
<spmlref:toPsoID ID='cn=test.subject.1,ou=testpeople,${base}'

Then, ldappcng, again acting as a ChangeLogConsumer, would execute
ModifyRequests which are created based on the PSOs calculated above.
For membership_adds, all attributes and references would added, while
for membership_deletes, all attributes and references would be

Perhaps an incremental provisioning design.


Archive powered by MHonArc 2.6.16.

Top of Page