graph level process listeners

[Paul Lorenz]

Hi all,
  I've been thinking about being able to specify process listeners at the graph level. I think there are many cases where you want a process listeners for all instances of a graph. This way, rather than having to add the listener to each instance of the process, it would be specified for the graph. Implementation would be similar to the process level, and we'd have to add one line to BaseEngine#fireEvent

  public EventActions fireEvent (final ExecutionEvent event)
  {
    EventActions actions = globalEventQueue.fireEvent( event );
    actions.compose( event.getProcess().getGraph().getEventQueue().fireEvent( event ) );
    return actions.compose( event.getProcess().getEventQueue().fireEvent( event ) );
  }

I'm not sure what form it should take in the process definition. Easiest would be something like:

<process-definition ....>
  <listeners>
    <listener type="com...MyExecutionListener" mask="8"/>
  </listeners>
</process-definition>

However, there are two issues here. The first is that the mask isn't very friendly for hand editing. However, any other format would be potentially very verbose.

<listener type="com...MyExecutionListener">
  <event name="PROCESS_CREATED"/>
</listener>

The other is that I don't like putting class names in process definitions, as it reduces the portability. So one could have:

<listener type="myListener">
  <event name="PROCESS_CREATED"/>
</listener>

But then you need a way to map type names to classes, much like with node types.

Does anyone have any preferences here?

thanks,
Paul

[Vincent Kirsch]

Hi,

1. The question I ask myself is: is there really a point to being able to specify what events we want to listen to? I mean,one will only treat events he wants to in the listener's notify() method, right?

-> that would solve your 1st problem the easy way ;) If you wish to keep that possibility, there's probably no easy way to make it useful and not too verbose. An idea might be to create some groups of events, for example NODE_TOKEN_EVENTS, or CREATION_EVENTS, etc. but I guess it might lead to a lot of different combinations, making it a little overkill. And I think that using the mask as in your first example should be avoided.

2. Regarding the class name issue, I don't think it's as complex as a node. If you look at how to register a listener via Engine#addExecutionListener(), you need to pass a class, and then a call to newInstance() is performed on that class; you could do the same from the definition file using Class.forName(String).newInstance() - there's no need to load custom tags etc.

Now for the portability issue, I guess what you mean is that by requiring a fully qualified name, the xml file wouldn't work with, say, the Haskell version of Sarasvati (right?).

In that case, the simplest thing to do is probably to do like this:

<listener type="MyListener">

 <blah blah blah>

</listener>

<listener-type name="MyListener">

  <java classname="com.mybusiness.listeners.MyListener"/>

</listener-type>

and then have each language-flavoured version of Sarasvati load its own <linstener-type> sub-tag only, i.e. the Java engine would look for a <java> tag, the Haskell for a <haskell>, etc. and they return an error if they don't find what they want. That way, you could use the same xml file with any version I guess.

Cheers,

Vincent

2009/9/8 Paul Lorenz <plo...@gmail.com>

[Cheong Chung Onn]

Hi Paul,

I am very happy with the current programmatic approach, would this
approach be deprecated after the implementation of your proposal? To me,
with the programmatic approach i can do last minute tweaking/patching
especially post deployment. Nevertheless I am in favor of graphical
declaration of process listeners, I prefer <onXEventType/> element as it
reflects its purpose and more succinct.

<process-definition>
<onProcessCreated trigger="MyListener"/>
</process-definition>

Regards
chung-onn

[Paul Lorenz]

On Tue, Sep 8, 2009 at 11:00 AM, Vincent Kirsch <vincent...@gmail.com> wrote:

Hi,

1. The question I ask myself is: is there really a point to being able to specify what events we want to listen to? I mean,one will only treat events he wants to in the listener's notify() method, right?

-> that would solve your 1st problem the easy way ;) If you wish to keep that possibility, there's probably no easy way to make it useful and not too verbose. An idea might be to create some groups of events, for example NODE_TOKEN_EVENTS, or CREATION_EVENTS, etc. but I guess it might lead to a lot of different combinations, making it a little overkill. And I think that using the mask as in your first example should be avoided.

There are two likely cases:
  1. You want all events
  2. You only want a few events.

So how about this: If you specify no events, you get them all. If you specify events, you only get the requested events.
 

2. Regarding the class name issue, I don't think it's as complex as a node. If you look at how to register a listener via Engine#addExecutionListener(), you need to pass a class, and then a call to newInstance() is performed on that class; you could do the same from the definition file using Class.forName(String).newInstance() - there's no need to load custom tags etc.

Now for the portability issue, I guess what you mean is that by requiring a fully qualified name, the xml file wouldn't work with, say, the Haskell version of Sarasvati (right?).

In that case, the simplest thing to do is probably to do like this:

<listener type="MyListener">

 <blah blah blah>

</listener>

<listener-type name="MyListener">

  <java classname="com.mybusiness.listeners.MyListener"/>

</listener-type>

and then have each language-flavoured version of Sarasvati load its own <linstener-type> sub-tag only, i.e. the Java engine would look for a <java> tag, the Haskell for a <haskell>, etc. and they return an error if they don't find what they want. That way, you could use the same xml file with any version I guess.

I think you're right, and I'm not going to worry about. This is one of those, wait until it's needed, then redesign things. If someone requests it some day, we can deal with it then.
 

[Paul Lorenz]

I won't be removing anything. This is strictly in addition to the current functionality.

I'm not really keen on <onEventType/>, as it's succinct only if you are interested in a limited number of events. With the following refinement from my previous email, I think the following will work

<listener type="com..MyListener"/>

will register MyListener for all events.

<listener type="com..MyListener">
  <event type="NODE_TOKEN_CREATED"/>
</listener>

will only only register MyListener for the node token created event.

Does that sound reasonable?

Paul

[Cheong Chung Onn]

Since the number of events that can be emitted by Sarasvati are both
finite and limited and hence i suggested the OnEventType tag. Further,
newer tag can be added to cater for newer events. Perhaps the only
downside is that it is not generic enough cater for future unforeseen
needs but then again I think currently Sarasvati already cover most if
not all those events.

Anyway, I am already happy with what Sarasvati provides, anything else
would be a bonus :)

Cheers!
chung-onn