2 Replies Latest reply on Mar 8, 2012 4:57 PM by akrambenaissi

    Modeshape does not support JournalEvent: any Workaround?


      Hi Modeshape World,


      According to Javadoc, it seems that modeshape ObservationManager does not support JournalEvent feature (as of JCR 2.0 spec). However, it seems that Observation is implemented and I put it in place it works great .


      There are a few discussions opened on the forum about sending events occuring on a repository to JMS queues for example to update database.


      So my question is: Is there any workaround to the non-support of JournalEvent? As suggested, using the observation feature may help in this case. The issue is probably that it only listens on one workspace. So, it will require to add listeners on all the workspaces of all repository.


      Any suggestion? What about dealing with long-sessions ? That may cause issues for the long term? Using JMS or any other asychronous mecanism may cause issues in case of high load, where journal events may not be written fast enough.




        • 1. Re: Modeshape does not support JournalEvent: any Workaround?

          You correctly state that ModeShape doesn't currently support journaled observation. However, it probably wouldn't be terribly complicated to implement something that uses Observation to log events to a database or other store. Using a JMS (durable) queue as you suggest would nicely decouple the receiving of the events (via your listener implementations) from the processing/storage of those events.


          You would need to register listeners for each workspace. Also, long-running sessions are not a problem if you're just registering listeners; I'd recommend not using that session for anything else. Instead, if the listeners need to load nodes, they should use new sessions.


          We would like to implement journaling, but it's lower priority on our roadmap at the moment.

          • 2. Re: Modeshape does not support JournalEvent: any Workaround?

            Thank you for the feedback.

            I implemented it this way it worked well.

            As an additional feature, I needed to query my Journal againts a certain key, so I added a MessageDrivenBean that then persist the message informations in a relationnal database.


            It probably could avoided by letting the messages on a queue and set a selector on my filter key, and then pass a different clientId to get the journal messages.