Le 07/02/2017 à 10:56, s_humbi a écrit : > I was playing around a little bit with triggers and stored procedures. > > For me (as beginner) almost everything worked fine, except this big problem > (don't know if it is a bug or if i did something wrong): > If you restart the server, the attribute triggerExecutionSubentry in the > subentry gets lost... > [10:52:14] WARN [org.apache.directory.server.core.trigger.TriggerSpecCache] - > Found triggerExecutionSubentry 'cn=trigger,dc=ds,dc=test,dc=net' without any > prescriptiveTriggerSpecification
What is the content of the cn=trigger,dc=ds,dc=test,dc=net entry ? You should have a prescriptiveTriggerSpecification attributeType in it pointing to the triggerExecutionSubentry entry. (actually, this is one of the pitfalls in this approach, as this attributeType should be virtual, not physical : the server *knows* which entries are part of the subentry's selected entries, and we can dynamically add this attributeType when teh entry is requested by a client. Sadly, we currently expect the entry itself to contain this element...) > > > This is what i found out (without warranty, comments/imporovements welcome). > Maybe it helps a little bit. > > Approach: > > 1 Implementing Stored Procedure > 2 Adding entry for Stored Procedure > 3 Adding the trigger as Attritbute (trigger for one Entry only) > 4 Or adding Triggers for more Entries, e.g. (Sub)-Tree > 5 Activate and deactivate Triggers > > > More docs: > http://joacim.breiler.com/apacheds/ch09s02.html#Planned%20New%20Features%20for%20Triggers > http://people.apache.org/~ersiner/ldapcon.2007/LDAPcon.2007_LDAP.Stored.Procedures.and.Triggers.in.ApacheDS_by.Ersin.Er_Paper.pdf > > > 1 Implementing the Stored Procedure > > Stored Prodedure are simple POJO with one or more public static methods > (later called by the trigger). > > Example: > > package com.test; > > import java.util.ArrayList; > import org.apache.directory.api.ldap.model.entry.Entry; > import org.apache.directory.api.ldap.model.entry.Modification; > > public class TestTriggerInterceptor { > > public static void helloTrigger(Entry oldEntry, ArrayList<Modification> > mods ) { > System.out.println("Entry found: " + oldEntry.getDn()); > > for (Modification modification : mods) { > System.out.println(modification.getOperation() > + " " > + modification.getAttribute()); > } > } > } yes. This need to be documented, because there is many more to say about this POJO, but basically, it's quite simple. One aspect that absolutely *need* to be re-worked is teh security aspect of this approach. Basically, we are giving a hell lot of power to those being able to inject a storedProcedure into the server. ACIs can be a first step, but we need more, and that may involve Java security. As I said, all this trigger/SP feature is highly experimental, and is currently not our main point of interest (there are a LOT of other basic aspects that need our focus atm). But we would be really pleased to see people being involved in it. As usual, contributions are very welcomed ! > > > 2 Adding Stored Procedures > > Adding a new ou for triggers, for example: ou=Stored Procedures,ou=system > > Adding a new entry (=StoredProcedure) for saving the StoredProcedure > (ObjectClass javaStoredProcUnit) > > Example: > > DN: storedProcUnitName=com.test.TestTriggerInterceptor,ou=Stored > Procedures,ou=system > > Definition LDAP Stored Procedure: > > • ObjectClass: javaStoredProcUnit and storedProcUnit > > • storedProcUnitName: complete classname, e.g. > com.test.TestTriggerInterceptor > • storedProcLangId: always “Java” > • javaByteCode: Upload byte-code with ds-studio (the .class - File) > > > 3 Adding the trigger as Attritbute for one Entry only: > > Adding the attribut entryTriggerSpecification in the entry. > > The Value of the Attribute entryTriggerSpecification is the trigger, example: > AFTER Modify CALL "com.test.TestTriggerInterceptor:helloTrigger" ($oldEntry, > $modification); > > --> helloTrigger is the public static Method, we implemented above > > Possible Triggers: > • AFTER Modify CALL > • AFTER Add CALL … > • AFTER Delete CALL … > • AFTER ModifyDN CALL … > > > Some possible parameters for the trigger: > (found in org.apache.directory.api.ldap.trigger.StoredProcedureParameter): > > Modify_OBJECT( "$object" ) > Modify_MODIFICATION( "$modification" ) > Modify_OLD_ENTRY( "$oldEntry" ) > Modify_NEW_ENTRY( "$newEntry" ) > Add_ENTRY( "$entry" ) > Add_ATTRIBUTES( "$attributes" ) > Delete_NAME( "$name" ) > Delete_DELETED_ENTRY( "$deletedEntry" ) > ModifyDN_ENTRY( "$entry" ) > ModifyDN_NEW_RDN( "$newrdn" ) > ModifyDN_DELETE_OLD_RDN( "$deleteoldrdn" ) > ModifyDN_NEW_SUPERIOR( "$newSuperior" ) > ModifyDN_OLD_RDN( "$oldRDN" ) > ModifyDN_OLD_SUPERIOR_DN( "$oldRDN" ) > ModifyDN_NEW_DN( "$oldRDN" ) > > Examples for static mehtods and trigger attribute entryTriggerSpecification: > > Static method: public static void changeTrigger(Entry entry, > ArrayList<Modification> mods ) { … } > Trigger: AFTER Modify CALL "com.test.TriggerInterceptor:changeTrigger" > ($oldEntry, $modification); > > Static method: public static void addTrigger(Dn newEntryDn, Entry addEntry ) > { … } > Trigger: AFTER Add CALL "com.test.TriggerInterceptor:addTrigger" > ($entry, $attributes ); > > Static method: public static void deleteTrigger(Entry deleteEntry) { … } > Trigger: AFTER Delete CALL " com.test.TriggerInterceptor:deleteTrigger" > ($deletedEntry); > > > 4 Adding Triggers for more Entries, e.g. (Sub)-Tree > First: Adding an Administrative Area for Triggers > > --> adding new attribute administrativeRole with the Value > triggerExecutionSpecificArea (didn't tries triggerExecutionInnerArea, don't > what this is for) Administrative Areas come in 3 flavors : - AAA : Autonomous Administrative Area. It covers a part of the DIT for all the possible roles (it includes the TriggerEecution role, but also the SubSchema/CollectiveAttribute and AccessControl roles) - SAA : Specific Administrative Area. It covers a part of the DIT for one specific role. - IAA : Inner Administrative Area. It covers a part of the DIT inside another AAA/SAA/IAA. In some way, it defines a specialisation. In the context of your question, the triggerExecutionInnerArea defines some specific rules that apply to a part of teh DIT that is already inside a triggerExecutionSpecificArea, or an AutonomousArea. It may also override another IAA. I suggest you read http://directory.apache.org/apacheds/advanced-ug/3-admin-model.html -- Emmanuel Lecharny Symas.com directory.apache.org
