No. Event's don't have payload. It might be interesting if they did. You can still outject any shared data you want available. If you didn't want the data to stay around long, I suppose you could even associate it with the event context, (scoped to the request, essentially) but I'm guessing that most of the data you would would normal be easily available elsewhere so it shouldn't be that big of a deal.
I guess the theory in Seam is that the event "payload" is held in the contexts. ie. if you look at how all other events (jsf events, jbpm events, etc) work, the idea is that you don't couple your event listener to the event it is listening to via some Event object, instead, the event listener has no parameters and simply pulls state from the contexts. In a sense, an Event object is a hack for carrying information about contextual state in architectures which do not have well-defined contexts.
However, I am not religious about this, and if people want it, I can probably make the signature of raiseEvent() be raiseEvent(String, Object...), and then try to match the varargs off against the parameters of the listener method. But notice how this really does couple the event producer more tightly to the consumer.
(I would have some problems with polymorphic type matching of parameters to overloaded listener methods, but those problems are probably not insurmountable.)
Seam component base framwork seems to be promoting the idea of strong cohesion and very very lose coupling.
Let me talk about the needs where Event consumer might expect some input from event producer.
1) Send email to the conserned persons only.
2) Perfrom DB operations on some specific data.
3) Invoke some specific Message Driven Beans(JMS)
To genralize the Idea of data container for event consumer we can use event context( Idea came from discussion).
Q1) Should we go for Event Types?[Changes in implementation required]
Q2) Should we use raiseEvents(String, Object...)?[ Changes in implementation required]
Q3) Event Context as a container is good enough?[ Can be consider as a very heavy container in some scenario]
What can be the best possible solution?
Thanks for your input.
I have used component driven events a few times in my application and have found having the payload in contexts to be good.
I think that it 'fits' well with seam design: the data/objects required by the consumer may be from the payload, or from session or application contexts. By using the event context for the payload it provides a single method for accessing the data required.
It is (I think) less easy to understand so perhaps could benefit from an example?