avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: Context: usage recommendations? ( Re: [SUMMARY] Context )
Date Tue, 03 Dec 2002 18:50:13 GMT

Neeme Praks wrote:

> Stephen McConnell ::
>> One or more component authors (like those James guys) - let's imagine
>> they want to lock a component into a suiside pact and as such - their
>> component needs a shutdown service.  When the component hits
>> requestShutdown() their component is going die - ok, that's cool -
>> perhaps the component is running under the mailet API and what it really
>> needs is a reserection (but that's a thread for next year) - aside from
>> that - problem is their component needs to be able to say "I need to
>> make request to the thing that started me up in the first place".  This
>> is not the same semantics as a classic lookup() or get().  The issue -
>> how can we convey that notion that the component is requesting a service
>> from a provider that it intrisic to its own existance - that's what I'm
>> trying to distinguish here - the notion of a privaliged request. Its
>> priviliged if it's from sibling to parent.  A shutdown request is one
>> example, other examples include notification of state change, request
>> for re-deployment etc.
> I'm not really fond of the distinction between priviledged and 
> non-priviledged services...
> How about then one more (optional) "lifescycle extension", e.g:
> public interface Child {
>     void setParent(Parent parent);
> }
> And then this "parent" object would follow the same semantics as has 
> been proposed for Context:
> ShutDownableParent shutDownableParent = (ShutDownableParent) 
> parent.getInterface(ShutDownableParent.class);
> shutDownableParent.requestShutdown();
> (or whatever flavour of the extended context methods you prefer)
> Or am I totally wandering in the dark here...

If your wandering around in the dark - be careful - you will probably 
bump in me becasue I'm wandering in the dark a little myself. I have 
been thinking about the lifecycle extension take on this as well - and 
my impressions is that for the case of "requestShutdown" etc. it a 
cleaner approach than extending context - but at the same time I also 
think that all it does is shift the real problem of access to a 
priviledged parent-child context - after all - how does the extension 
handler get a reference to the container ?  Even if it has a reference 
to the container - you still need an operation on the container to 
request shutdown.  

About all I can draw out of the requestShutdown example is that there is 
perhaps a need for some standard interface that can be provided by a 
container to handle child request - and, that the container 
implememntation still needs to know that the handler needs privaliged 
(i.e. container sourced) information.

But anyway - what I can draw from things at the moment is that there is 
perhaps a meta model issue here.  At the meta model level we have the 
notions of context criteria and service depedencies as different 
abstractions and container map these respective notions into the SM/CM 
and Context implemetations provided to the component.  Adam Murdoch is 
persistently raising a bunch of good question that suggest that there 
may be a more deeply rooted problem - for example, imagine I drop 
Contextexulizable/Servicable seperation - I could rework stuff in the 
containers I use to handle this - instead of apply 
get("urn:avalon:work") to a context you could instead apply 
lookup("urn:avalon:work) to a common handler.

But if context/service seperation dissapeared I know I'm still missing 
something important - and I think its about granulirity in lifecycle - 
i.e. does reservicing imply re contextualization - does 
recontextualization imply reservicing.  If recontextualization can occur 
without reservicing than we have a distinct abstraction.  But I'm well 
an trully in the perculating thoughts stage on this.

Cheers, Steve.

> Rgds,
> Neeme
> -- 
> To unsubscribe, e-mail:   
> <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: 
> <mailto:avalon-dev-help@jakarta.apache.org>


Stephen J. McConnell

digital products for a global economy

To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>

View raw message