> > On Oct 20, 2016, at 8:43 AM, Steve Moyer <[email protected]> wrote: > > Looking through the AdminMgr methods, I'd propose the following methods be > added to the interface (I'll turn it into a Jira issue when we're done with > the discussion): > > User addUser(User user, EntryCallback<User> callback); > void deleteUser(User user, EntryCallback<User> callback); > User updateUser(User user, EntryCallback<User> callback); > > The User class would need one additional method - this would be very useful > just to further inspect retrieved objects but is also required within an > EntryCallback: > > Entry getEntry(); > > The EntryCallback interface would look something like: > > @FunctionalInterface > public interface EntryCallback<T extends FortressEntity> { > > Entry transform(T fortressEntity) throws FortressOperationAbortedException; > > }
Steve, why do say that the callback req’s the getEntry on entity? Why couldn’t it go on the interface? > Entry transform(T fortressEntity, LdapEntry entry) throws > FortressOperationAbortedException; > > On Oct 20, 2016, at 8:43 AM, Steve Moyer <[email protected]> wrote: > > I originally excluded the use of a callback on the delete operation but > having a callback allows the operation to be aborted (Based on values in the > entry? Or when referential integrity with other entries might be violated?). > As noted, having access to the underlying groupOfNames entry would also be > useful. I'd argue that you would commonly expect User and Group to be more > complex than Fortress' view of them since it's common to write schema > extensions for them. I'd also argue that Roles, Permissions, etc are > specifically Fortress implementations of the RBAC specification and they > should remain black boxes to other LDAP operations. > > What do you think? +1 (other than not exposing the model to the ldapentry) Agree that only user and groups are extended in this way. The other entities should be left alone, excepting some sort of generic property capability. Shawn
