Grouper Developers Forum

[Chris Hyzer <>]

It's the object you already have right?  Want to just stash in a thread local 
or temporary static lookup so we don't have to hit the db for something we 
already have?  But yes, we can easily add that method, if you want to, go for 
it, or if you want me to, I can do that no problem

Thanks,
Chris

-----Original Message-----
From: 

 
[mailto:]
 On Behalf Of Tom Zeller
Sent: Thursday, April 28, 2011 11:01 PM
To: Grouper Dev
Subject: [grouper-dev] [ldappcng] incremental provisioning : find 
ChangeLogEntry by id ?

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" ... />
  </references>
 </object>

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();
   calcRequest.setId(changeLogEntry.getId());
   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'/>
    <capabilityData>
      <spmlref:reference typeOfReference='member'>
        <spmlref:toPsoID ID='cn=test.subject.1,ou=testpeople,${base}'
targetID='ldap'/>
      </spmlref:reference>
    </capabilityData>
  </ldappc:pso>

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

Perhaps an incremental provisioning design.

TomZ