Lifecycle and eventing, was: [jira] Commented: (TUSCANY-63) ...

[Jeremy Boynes <jb...@apache.org>]

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

Re: Lifecycle and eventing, was: [jira] Commented: (TUSCANY-63) ...

[Jim Marino <jm...@myroma.net>]

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
>