> On Oct 21, 2016, at 9:07 AM, Steve Moyer <[email protected]> wrote: > > The use case I originally described was that when I performed a findUsers() > call via the ReviewMgr, I had no way to retrieve the additional data that > came from the underlying Entry. I was therefore repeating the query using > the LDAP API, then merging together the requisite fields to output a SCIM > user via the REST interface. So my original request was to be able to get > the underlying LDAP entry for each FortEntity I was processing. I think the > most straightforward way to do this is with the method I described: > > Entry getEntry();
The problem with that approach, other than exposing an LDAP specific object to a model object, is it still doesn’t satisfy the requirement of pulling the additional attributes. That is because the ldapsearch op must specify the additional attributes by name which of course in this scenario would not have happened meaning the additional attributes you seek won’t be in the entry. It may be helpful to explain one of the key design aspects of this system, that of encapsulating details of the backend from the caller. The reason is simple - additional backends could be supported at any time in the future w/out impacting systems dependent. Theoretically apps using fortress, could swap out the LDAP impl with a database (for example), without the api invocations having to change. If we expose elements of the backend to the model and API interface that can’t happen. Obviously adding a callback interface subverts this somewhat, but only for those choosing to implement it, presuming they know what they’re doing, and what the risks are. > > On Oct 21, 2016, at 9:07 AM, Steve Moyer <[email protected]> wrote: > > Again, this method would only need to go on the entry types that are not > Fortress specific (User and Group). With respect to the transform method, I > originally had: > > Entry transform(Entry entry) throws FortressOperationAbortedException; > > This forces every callback to treat the supplied data as an LDAP Entry and it > occurred to me that some people might actually just want to do > post-processing on the FortEntity. And since the FortEntity in question > already had a getEntry() method (per my first use case), it seemed redundant > to pass both to the callbacks. One question - in your method signature > above, is the fortressEntity simply a "refined" view of the (mutable) entry? > If not, you could end up with some real problems producing the returned LDAP > Entry. Yes I understand what you’re trying to do, understand it would only be for one or two entities, but for reasons previously stated, am opposed to adding the entry getter to model. Here is the callback as listed before: > Entry transform(T fortressEntity, LdapEntry entry) throws > FortressOperationAbortedException; The fortressEntity would be this: http://directory.apache.org/fortress/gen-docs/latest/apidocs/org/apache/directory/fortress/core/model/FortEntity.html which is the base class allowing any other entity to be passed back as an argument allowing full access to all attributes already pulled from entry, and provides opportunity to add / replace additional attributes as needed. Thanks, Shawn
