On Mar 5, 2006, at 8:09 AM, Jeremy Boynes wrote:
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.
Yes but the one issue that prevented me from doing this initially was
the ability to have custom scope types and events. We could have some
"precanned" methods since fireEvent(EventContext.REQUEST_START,null);
is ugly looking but I think we need a general mechanism that allows
things such as transport bindings to notify the runtime of various
events. In addition to scopes, I can see such events as:
"binding for entry point/external service is changed"
"introduce this policy on these types of entry points"
Also, right now there are two event notification mechanism, the
fireEvent associated with AggregateContext and LifecycleEventListener
for being notified of new component instance creation. Perhaps these
should be reconciled? I'm not sure.
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.
This seems reasonable.
--
Jeremy
