Return-Path: Delivered-To: apmail-jakarta-avalon-dev-archive@apache.org Received: (qmail 91655 invoked from network); 2 Jul 2002 14:03:57 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 2 Jul 2002 14:03:57 -0000 Received: (qmail 23993 invoked by uid 97); 2 Jul 2002 14:04:06 -0000 Delivered-To: qmlist-jakarta-archive-avalon-dev@jakarta.apache.org Received: (qmail 23913 invoked by uid 97); 2 Jul 2002 14:04:05 -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 23900 invoked by uid 98); 2 Jul 2002 14:04:05 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Message-ID: <3D21B346.6000608@osm.net> Date: Tue, 02 Jul 2002 16:05:58 +0200 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: [ISSUE] containerkit References: <3D212869.7020407@osm.net> <5.1.0.14.2.20020702161056.01bb8008@mail.optushome.com.au> 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 Peter Donald wrote: > At 08:04 AM 7/2/2002 +0200, you wrote: > >> What are the constraints that Context needs? > > > Runtime values and services provided by container. > >> Let me also be the devil's advocate again: what is Context for? >> >> ie is it good practice to do in contextualize(Context context) >> >> MYContext mc = (MYContext) context; > > > I prefer this option - for no real good reason except that I find it > easier to use. > >> ? >> >> Or to do >> >> MYContext mc = context.get(MY_CONTEXT); > > > Another option. > >> The latter is done in Cocoon, and has created enourmous confusion to >> our users (of course, this is not an Avalon deficiency per se, but it >> shows how it has been used). >> >> Is it good practice to use Contexts to aquire common services? > > > Depends who is supplying the service. If the container is supplying > the service and is the only one capable of supplying service then the > context is the method via which to expose service. If it is just a > common service then it should be supplied to all users via > ServiceManager. > > Example services that only container can provide; > * Modification/Saving of Configuration object > * Access to ClassLoader hierarchy of app > * Access to ThreadGroup hierarchy of app > * Access to various code-based Security policys > * name of component > etc Not so keen on the above approach - seems to me like it is mixing service and context. When something needs a "service" it should go though the service manager as a result of a formal dependecy declaration. In you avaove list you include the "name of the component" - presumably that would be a java.lang.String (which isn't a component and cannot be declared as a dependecy) which would be an appropriate value to pass through context. > >> IMHO this is not so good, since it's recreating what Serviceable does. >> >> As it seems now, a Context works as a common ServiceManager. > > > Right - which is wrong. Context should not be used as a common services manager - that would break the service management model. > > Stephen also treats it in a similar way except wrt to configuration. > ie He places global config values in there and treats it as an > alternative mechanism to configure components. Much better to use > Configuration objects (or Parameters objects). Stephen does not do the above! Stephen is wondering why Pete is saying this instead of addressing the real issue. Cheers, Steve. -- 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: