Jim Marino (JIRA) wrote: > [ > http://issues.apache.org/jira/browse/TUSCANY-63?page=comments#action_12368832 > ] > > Jim Marino commented on TUSCANY-63: > ----------------------------------- > > We may have to think about a general eventing mechanism in the > runtime (there is the basic EventContext stuff)...We could perhaps > have the builder prepare everything and hand the configuration to the > registry which can then send a notification to the transport, in this > case Axis. Axis won 't "turn on" the entry point until it is > notified during a MODULE_START event. > >
I agree we need to reexamine the eventing and lifecycle model in general. Having external code able to fire general events is something that has seemed a little squirrely to me with the potential it has allowing that code to trigger inappropriate behaviour. For example, to start a module context the code calls fireEvent passing in the MODULE_START parameter. Instead, would it be possible to have start/stop methods on the context itself to control its lifecycle and then have their implementation send a MODULE_START event as a notification to other components that the context had started. With explicit control over lifecycle we can make an AggregrateContext responsible for starting its children. Specifically, it would recursively start the child contexts that represent the EPs, Components and ESs that its Module contains. Envision that during the build phase, the builder set up enough configuration information in the EP context and its binding so that that context knows how to start and register itself. For example, the builder would have configured the Axis2 binding with all of its Axis configuration information and a reference to the Axis engine via the SPI. When the EP starts it in turn starts the inbound binding which will then use the SPI implemented by the Axis engine to register and activate itself. -- Jeremy
