On Thu, Nov 12, 2009 at 9:32 AM, Sergio Bossa <sergio.bo...@gmail.com>wrote:

I know, I know, that's why I was recently considering to add to

Yes, I think this would be great. In case I'm really running into problems
with the sequantial execution of handlers, I'll try to implement something
in this direction and keep you updated of course.

Another idea I had: for my use case it would be nice to have more
flexibility regarding the selection of the handler method on the actor.
Currently, there is always the CoreHandler used internally but it would be
nice to plug in custom logic there.

For example, it would be very useful to have something along these lines:

class MyHandler {

@OnMessage(type = Message.class)
void handleFooMessage(Message msg) {...} // handles messages of type foo

@OnMessage(type = Message.class)
void handleBarMessage(Message msg) {...} // handles messages of type bar

The current implementation of course does not know which handler to call
here, so I am using more specific types in the @OnMessage annotation.
However, since I get a generic Message from the 3rd party app, I had to plug
in a factory that creates a more specific Message from the generic Message
before calling the send method on the actor (but in many cases, I don't need
this more specific Message later on).

so I would need to inject a CoreHandler when spawning the new actors (e.g.
something called MyCoreHandler that extends CoreHandler and overrides
handleOnMessage). I could then analyze the method name with reflection,
compare it with the message type of the currently processed message and then
dispatch based on this.

Could I make myself clear? :) What do you think? Does this make sense?

Best,

Stefan