1 2 Previous Next 17 Replies Latest reply on Dec 8, 2008 9:50 AM by Bernd Ruecker

    Register EventListener on JbppmContext

    Bernd Ruecker Master

      Hi.

      Yesterday I was at customer and they did an extension to jbpm where they added the possibility to add EventListener to the JbpmContext (configured via jbpm.cfg.xml).

      Today I face a similar problem, it would be interesting to get notified if each event fired inside the engine (basically to catch them and maybe throw the aggregated to some BAM engine).

      What do you guys think, include such a feature in jbpm core? I think it is an interesting one without bit complexity. Also the guys from yesterday could provide some code for it (Tom, I heard there is a pending committer status request from them), so maybe it wouldn't be that hard...

      Opinions?

      Cheers
      Bernd

        • 1. Re: Register EventListener on JbppmContext
          Mauricio Salatino Master

          Great, let me know if you upload some code to the repository to check it out!

          • 2. Re: Register EventListener on JbppmContext
            Bernd Ruecker Master

            Currently I am waiting for some feedback before committing, but the longer I think about it, the more valuable the feature looks to me...

            • 3. Re: Register EventListener on JbppmContext
              Thomas Diesler Master

              This has been taken out of the 1-Jan cut of the API because we did not get to the general notion of Signals + Messages.

              Nevertheless, I also think this is a valid concept. Here are the API drafts for it

              SignalService
              http://www.jboss.org/community/docs/DOC-12891

              MessageService
              http://www.jboss.org/community/docs/DOC-12889

              • 4. Re: Register EventListener on JbppmContext
                Ronald van Kuijk Master

                @Bernd:

                Yes would be great. Compare this solution to adding actions to each node (or generic events in the processdefinition) that is e.g. needed for SeeWhy.

                @Thomas:
                I think messages and signals are not necessarily the same as what Bernd proposes. Messages and Signals from BPMN are Business level things, where as what Bernd proposes is more like an extension to the engine itself to make it even more flexible.

                • 5. Re: Register EventListener on JbppmContext
                  Tom Baeyens Master

                   

                  "camunda" wrote:
                  Hi.

                  Yesterday I was at customer and they did an extension to jbpm where they added the possibility to add EventListener to the JbpmContext (configured via jbpm.cfg.xml).

                  Today I face a similar problem, it would be interesting to get notified if each event fired inside the engine (basically to catch them and maybe throw the aggregated to some BAM engine).

                  What do you guys think, include such a feature in jbpm core? I think it is an interesting one without bit complexity. Also the guys from yesterday could provide some code for it (Tom, I heard there is a pending committer status request from them), so maybe it wouldn't be that hard...

                  Opinions?

                  Cheers
                  Bernd


                  all our jbpm 3 efforts are now focussed on increasing the stability and test coverage (mainly dbs).

                  this feature should be discussed in terms of jbpm4. in that context, it might be an option to leverage the environment for that. after a event propagated all the way up to the environment, it could be propagated further on the environment contexts. good idea, but needs some more reflection. performance might become an issue so it should be possible somehow to configure which events are propagated to the environment like that.

                  • 6. Re: Register EventListener on JbppmContext
                    Bernd Ruecker Master

                    @Thomas: I also the events I want to listen for are more inside of the engine (so implementation detail ;-)). But the Listeners you propose also make sense, even if I don't understand the API at this part yet...

                    @Tom: I expected you to say that ;-) And I agree with you, but for me the situation is not putting effort in jbpm 3 or 4, but to solve the problem in the customer project either by some workarounds around jbpm (in "our" code) or to implement it correctly in the jbpm 3 core. Effort could be maybe the same. So I think it makes more sense to contribute it to jbpm and maybe even gather experiences for jbpm 4. And even jbpm 3 will be around for quite a while I think...

                    So if you don't vote explicitly against it I would maybe contribute it if it comes to that point in the current project (concept isn't yet fixed), ok?

                    • 7. Re: Register EventListener on JbppmContext
                      Tom Baeyens Master

                      regrettably at this point we don't even have the bandwidth to verify the contributions on jbpm3. also we don't yet have the separate branch in place so that we more easily can accept community contributions and validate those before we actually adopt them into the stable branch.

                      • 8. Re: Register EventListener on JbppmContext
                        Bernd Ruecker Master

                        Meaning what exactly in respect to my question?
                        By the way: Of course I would provide test cases as well...

                        • 9. Re: Register EventListener on JbppmContext
                          Bernd Ruecker Master

                          Okay, here my proposal.

                          Add to GraphElement:

                           /**
                           * notify configured external event listeners of fired event.
                           *
                           * The notification is done BEFORE the event gets processed by jbpm
                           * internally (meaning actions are executed), so it is visible
                           * to the listeners even if exceptions occur inside of the actions
                           * causing the stacktrace to abort
                           */
                           private void notifyListenerOfEvent(String eventType, ExecutionContext executionContext) {
                           EventListenerUtil.notifyListenerOfEvent(eventType, executionContext);
                           }
                          


                          and call this method inside of the "fireAndPropagateEvent" method.

                          Now my first thought was, that the EventListenerUtil looks up jbpm.cfg.xnml via JbpmConfiguration to see if there is a bean "jbpm.event.listener" configured, e.g.

                          <bean name="jbpm.event.listener" class="MyEventListener">
                          


                          Or to create some kind of jbpm event dispatcher to support a list of listeners:

                          <bean name="jbpm.event.dispatcher" class="org.jbpm.NN">
                           <field name="listeners">
                           <list>
                           <bean class="MyEventListener1" />
                           <bean class="MyEventListener2" />
                           </list>
                           </field>
                          </bean>
                          


                          The code isn't hard there, just check in the JbpmConfiguration if the listener is/the listeners are set and if then call the listener.

                          What do you guys think? What would you prefer, simple one listener (so people with multiple listeners have to implement that themselvers) or multiple listeners?

                          This is a really powerfull machnism to hook into jbpm and to develop generic solutions around it, e.g. for BAM.... And it is not a big deal. I would like to start on this next week, hopefully we can come to some conclusions here. When finished I can also blog about how I use this to generate the BAM events we need in the project...

                          Cheers and have a nice weekend
                          Bernd

                          • 10. Re: Register EventListener on JbppmContext
                            Bernd Ruecker Master

                            Damn it, submitted too early, now in the train (with a bit of fresh air in between) I had two additional thoughts:

                            1.) I think the single listener would enough. If we want to have something like a dispatcher it can be configured as Listener knowing a list of other listener it notifies.

                            2.) The EventListener is maybe really not important at the moment. I think the same thing is already supported by hook in an own LoggingService. This LoggingService gets all important events as Log as well, right? Or does anybody already dived deeper into it and knows something which is missing there?
                            So I can extend the LoggingService to serve as EventListener... I think for my purposes at the moment it should be sufficient. I will check that out on Monday morning....

                            So I think I started an unnecessary discussion, sorry for that! But finally it helped at least me to come to a solution ;-) Keep you posted about how I meet our BAM requirements...

                            • 11. Re: Register EventListener on JbppmContext
                              Bernd Ruecker Master

                              Okay, to give you the latest update:

                              For creating the events I need, I implemented an own LoggingService, which keeps a list of ProcessLog objects internally in memory. When closing the LoggingService, I look through these evens and create the necessary BAM events and send them to my BAM service.

                              One important issue was, to place the LoggingService BEFORE the PersistenceService, by doing so, the LoggingService can still access the HibernateSession (otherwise it would be closed earlier). This works if the loadForUpate methods where called everywhere correctly :-)

                              But I discussed that implementation with another guy, and we concluded, that the EventListener still is a valuable Feature. Because if you really want to listen for events, it is the right place. Logs are created much later (e.g. during jbpmContext.close) and have different granularity.

                              What does others think about that?

                              For my problem I am happy with the LoggingService, for the other project, they patched jbpm already to include the EventListener. But I think it would make sense, at least for jbpm 4.

                              • 12. Re: Register EventListener on JbppmContext
                                Tom Baeyens Master

                                i have been thinking of unifying the 3 types of 'events' that we have in jbpm:

                                * signals (incoming events, incoming from the perspective of the process engine)
                                * events (internal events)
                                * process logs (outgoing events)

                                would it be possible to unify those 3 ? on my first chew, i could not be sure that this would not have disadvantages on the flexibility. but somehow it feels very close...

                                • 13. Re: Register EventListener on JbppmContext
                                  Tom Baeyens Master

                                  ...because Bernd, what you describe is actually adding a logging listener to internal events. if we would unify them, then this would be replaced by just adding a generic (incoming, internal and outgoing) event listener.

                                  • 14. Re: Register EventListener on JbppmContext
                                    Tom Baeyens Master

                                    Only now i see the second page :-) So you already made the connection to the loggingservice yourself :-)

                                    1 2 Previous Next