Grouper Developers Forum

[Tom Zeller <>]

No. I think I need the method.

I have the ChangeLogEntry object in the ChangeLogConsumer, but I need
the ChangeLogDataConnector to query for the same object to calculate
provisioning via the AttributeResolver - which only consumes a string
identifier.

If you could add the method, great, otherwise send me a hint ...

On Fri, Apr 29, 2011 at 8:06 AM, Chris Hyzer 
<>
 wrote:
> 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
>