3 Replies Latest reply on Nov 29, 2007 5:10 PM by jdelaney

    document event listener behavior



      I'm extending DocumentListenerAdapter so that it pushes urls to our external enterprise search app for indexing.  So we would like urls to get pushed on publishing and delete actions so I am overriding documentAdded(),documentDeleted(),documentModified().  I noticed from my logging that when I delete a document, it seems to be calling documentModified action rather that documentDeleted:



      2007.11.28 19:37:05 Validating /doc-delete with method execute.

      2007.11.28 19:37:05 Invoking validate() on action com.jivesoftware.community.action.DocDeleteAction@7da150

      2007.11.28 19:37:05 cannot find method validateExecute in action com.jivesoftware.community.action.DocDeleteAction@7da150

      2007.11.28 19:37:05 cannot find method validateDoExecute in action com.jivesoftware.community.action.DocDeleteAction@7da150

      2007.11.28 19:37:05 Intercepting invocation to check for valid transaction token.

      2007.11.28 19:37:05 Executing action method = null

      2007.11.28 19:37:05 IN DOC MODIFY METHOD





      I'm pretty sure this was working in earlier versions but can't remember for sure (running 1.8 now).  I also noticed that if I edit a doc and click "Save as Draft" - it runs the documentModified action, but then if I publish it afterward, it doesn't run any action (since the doc wasn't re-modified) but of course we don't want to send the url to our indexer if it hasn't actually been published (since it would just hit the old published content url rather than the waiting-to-be-published content).  Is there a way to detect a Publish action so that we can make sure the indexer doesn't miss urls that get saved/modified and then published later (thought maybe versionadded action but it looks like that also fires off during "save draft" actions)?  I have also noticed in the logging that it seems the doc modify action sometimes fires off multiple times when a single doc gets modified - any ideas on that?  Thanks for any info.

        • Re: document event listener behavior

          Well actually I suppose I could just extend doc-delete and doc-publish actions (and version restore action) and include the listener execution code I have into those actions - just seems like it would be simpler to do it all in a listener.  Any potential caveats you see with taking the action approach as opposed to the listener approach?

            • Re: document event listener behavior

              hi James,


              Seems like the action approach would work most of the time, you might run into some edge cases where a document is rolled back to a previous version (and thus modified) or a document is modified via web services, but the doc-publish and doc-delete actions would probably cover 99% of the edits.





                • Re: document event listener behavior

                  Cool AJ. Yep went with the action approach and logging seems to indicate it will work - was already extending doc-restore since I also thought of that case when a previous version might get restored/modified so should be covered now, although I noticed I had to add the listener code to doc-create/doc-edit actions as well since I guess they don't invoke doc-publish at all (only doing the save draft + publish seems to invoke it).  Thanks for the info.