Return-Path: Delivered-To: apmail-jakarta-avalon-dev-archive@apache.org Received: (qmail 40433 invoked from network); 23 Nov 2002 22:59:25 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 23 Nov 2002 22:59:25 -0000 Received: (qmail 1627 invoked by uid 97); 23 Nov 2002 23:00:30 -0000 Delivered-To: qmlist-jakarta-archive-avalon-dev@jakarta.apache.org Received: (qmail 1611 invoked by uid 97); 23 Nov 2002 23:00:30 -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 1599 invoked by uid 98); 23 Nov 2002 23:00:29 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Content-Type: text/plain; charset="iso-8859-1" From: Darrell DeBoer To: "Avalon Developers List" Subject: Re: reduction ad unum Date: Sun, 24 Nov 2002 09:00:26 +1000 User-Agent: KMail/1.4.3 References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200211240900.26462.darrell@apache.org> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N >From another branch of this thread: On Sun, 24 Nov 2002 00:35, Stephen McConnell wrote: > In every single one of the examples you have provided above, the > extension of context is related to the exposure of a service. Take the > "forwardMail" example and image we want to create a component that is > complete and container agnostic. What we would do is declare that the > component in question has a dependency on a MailForwardingService. The > contract says nothing about where the service comes from (could be the > result of assembly, could be the result of a facility supplied by a > custom container). The point is that using *existing* Avalon Framework > contracts - this sort of dependency can be expressed providing we have a > consistent component model. Combine this with standard context entries > (avalon:home, avalon:work, etc) and the whole requirement for context > specialization disappears - or is at least pushed out into relatively > closed environments where component reuse outside of a particular > technical domain is of no interest. (I've replied to this in-thread.) I believe this solution is superior to extending the concept of a Context. If we can limit the use of "Context" to a very small set of standard entries, and use the regular service-dependency mechanism for anything that might be remotely container-specific, we avoid making this more complicated than it has to be. To be honest, I'm not sure we'd lose much by ridding ourselves of Contextualizable altogether - maybe make Context just another service (the GenericUntypedHashMapThatMayJustHaveWhatYoureLookingForButWeCantGuaranteeIt service ;). -- cheers, Darrell DeBoer -- To unsubscribe, e-mail: For additional commands, e-mail: