On 3/16/07, Enrique Rodriguez <[EMAIL PROTECTED]> wrote:
Hi, Directory developers,
Hi,
1) Has anyone given any thought to where we would put the initialization code for administrative triggers and stored procedure's? For review, in the ITest there are 2 key lines: a) Where the stored procedure is loaded: // Load the stored procedure unit which has the stored procedure to be triggered. JavaStoredProcedureUtils.loadStoredProcedureClass( ctx, BackupUtilities.class ); b) Where the trigger is added: // Create the Trigger Specification within a Trigger Subentry. createTriggerSubentry( ctx, "triggerSubentry1", "AFTER Delete CALL \"" + BackupUtilities.class.getName() + ".backupDeleted\" ( $ldapContext \"\", $name, $operationPrincipal, $deletedEntry )" );
These two methods are just for easing some tasks frequently used during working SP and Triggers. Don't consider them THE way to work with SPs and Triggers. You do not need to load SP and Triggers during start-up. They are persisted within the DIT. If ApacheDS one day comes with some SPs pre-loaded they will be added on the first start-up of server or they will be in the prepopulated partition. Subsequent SP and Trigger additions are regular LDAP operations that you can do whenever you want.
The use case here is that I would like to automatically derive Kerberos keys for users when they modify userPassword. So, I have an SP that I need to load into the DIT and I have a trigger that I need to set on the ou=users subtree. Short term this could be added to ServerContextFactory, after the backend is started and any LDIF's loaded. We could potentially have a lot of them for various server/admin tasks. 2) Also, what would the process look like for checking if the SP and trigger already exist? Would we just load/set them again since it's not harmful, like we do with loading LDIF's at startup?
They exist where you store them. They are currently just raw entries. They do not know they are SPs and Triggers, they are not handled in a special way. So just do a search/lookup for them.
3) What are the pros/cons with doing this with a trigger/SP vs. an Interceptor? The major thing is the "scope," right? Meaning a trigger/SP can apply to subtree/subtree refinements (TEDs), while an interceptor wouldn't have those semantics by default. Any other pros/cons?
Well, you can still work with scopes with Interceptors. In fact, as we're developing the core, we do not have to use SPs or Triggers for core functionality. It may be better to use Interceoptors. SPs and Triggers are more likely to be used by regular (administrator) users. One advantage of them is that they are completely user space constructs and are loaded and managed over LDAP; no need to touch server side code.
Enrique
BTW, I plan to work on these two stuff and their documentation this weekend so I suggest you stay tuned. HTH, Thanks. -- Ersin
