Matthieu, The dynamic overloading looks pretty good. Questions:
The timer will dispatch with TimerEvent. So to implement timer, the PE needs a processOutputEvent(TimerEvent event) right? I think this is fine, to reuse code, one can simply call another method in the PE. We can have this method combined with a different one that is triggered on each input or every N inputs. Those will need to use the expected input event type. When the method event type is Event, then it accepts all the input events, right? What happens if you send CountEvent and have methods: processInputEvent(CountEvent event) processInputEvent(Event event) Which method gets dispatched? The more specific one? The semantics seem to be as follows: processInputEvent(Event1 event) means dispatch on every input event of type Event1 processOutputEvent(Event2 event) means dispatch according to configuration (on every event, every N events, on event if timeout expired) where event is of type Event2. processOutputEvent(TimerEvent event) asynchronously with timer, dummy event is always of type TimerEvent A few thoughts: Input/Output names may not make a lot of sense any longer. What about changing to the following: processEvent(Event1 event) with any of the synchronous configurations. timerTask() called when there is a timer task configured. The timer task needs to be synchronized with the processEvent method (unless the PE has a @ThreadSafe annotation), we can keep the internal dummy event to synchronize but call timerTask() without an Event instead. I'm sure there are other ways of doing this. Does this make sense? We need to think a bit. -leo
