Here's a quick hint on how to isolate it really quickly:
Just use a test in core-integ like SubentryServiceForTriggersIT.testEntryAdd() delete the marked, "cn=marked,ou=configuration" entry. I already did this but I @Ignore the test class so you might want to remove that annotation up at the top. Run this test and you'll see the exception encountered when running the test.
We should be able to delete entries that are in the trigger specific area so I would suspect this is a bug.
On Dec 8, 2007 10:47 AM, Alex Karasulu <firstname.lastname@example.org> wrote:Ersin,
I am trying to get reverts working with SP code. There are some tricky things here however these are different points. What I need to know from you is why I get this stack trace here when trying to revert the changes of this test:
Here's the tail end of the trace:
Caused by: java.lang.StringIndexOutOfBoundsException: String index out of range: -1
at java.lang.String.substring (String.java:1938)
at org.apache.directory.server.core.sp.StoredProcExecutionManager.findStoredProcUnit (StoredProcExecutionManager.java:76)
at org.apache.directory.server.core.trigger.TriggerInterceptor.executeTrigger (TriggerInterceptor.java:578)
at org.apache.directory.server.core.trigger.TriggerInterceptor.delete (TriggerInterceptor.java:310)
... 60 more
The problem seems to stem from trying to extract the class name from this spec: " LogUtils.logDelete". Looks like this code tries to get the name of the class by finding the index of a ':' colon instead of a '.' - Why is that?
Because that's the SP syntax. Fully Qualified Stored Procedure Name = Stored Procedure Unit : Stored Procedure
I'll try to look further into the pb.
Here's the LDIF operation that causes this exception:
Entry : cn=marked,ou=configuration,ou=system
Change type is DELETE