Return-Path: Delivered-To: apmail-jakarta-avalon-dev-archive@apache.org Received: (qmail 15234 invoked from network); 3 Dec 2002 18:50:17 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 3 Dec 2002 18:50:16 -0000 Received: (qmail 11653 invoked by uid 97); 3 Dec 2002 18:51:20 -0000 Delivered-To: qmlist-jakarta-archive-avalon-dev@jakarta.apache.org Received: (qmail 11623 invoked by uid 97); 3 Dec 2002 18:51:19 -0000 Mailing-List: contact avalon-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Avalon Developers List" Reply-To: "Avalon Developers List" Delivered-To: mailing list avalon-dev@jakarta.apache.org Received: (qmail 11607 invoked by uid 98); 3 Dec 2002 18:51:19 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Message-ID: <3DECFCE5.9050708@apache.org> Date: Tue, 03 Dec 2002 19:50:13 +0100 From: Stephen McConnell User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en, en-us MIME-Version: 1.0 To: Avalon Developers List Subject: Re: Context: usage recommendations? ( Re: [SUMMARY] Context ) References: <001601c29a64$62fba020$6401a8c0@LEIBNIZ> <3DEC31A8.4040502@apache.org> <200212031553.19388.adammurdoch@apache.org> <3DEC515E.6000605@apache.org> <3DEC9BE2.5000105@apache.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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: > > For additional commands, e-mail: > > > > -- Stephen J. McConnell OSM SARL digital products for a global economy mailto:mcconnell@osm.net http://www.osm.net -- To unsubscribe, e-mail: For additional commands, e-mail: