Return-Path: Delivered-To: apmail-jakarta-avalon-dev-archive@apache.org Received: (qmail 84283 invoked from network); 24 Jul 2002 12:34:51 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 24 Jul 2002 12:34:50 -0000 Received: (qmail 409 invoked by uid 97); 24 Jul 2002 12:35:07 -0000 Delivered-To: qmlist-jakarta-archive-avalon-dev@jakarta.apache.org Received: (qmail 375 invoked by uid 97); 24 Jul 2002 12:35:06 -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 361 invoked by uid 98); 24 Jul 2002 12:35:05 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) Message-ID: <3D3E9EC4.9030707@apache.org> Date: Wed, 24 Jul 2002 14:34:12 +0200 From: Nicola Ken Barozzi Reply-To: nicolaken@apache.org Organization: Apache Software Foundation User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Avalon Developers List Subject: Re: [lang] Submission of Avalon.Excalibur.ThreadContext References: <002301c2324e$abe2ca80$ac00a8c0@Gabriel> <200207242009.25550.peter@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 Peter Donald wrote: > On Tue, 23 Jul 2002 23:41, Berin Loritsch wrote: > >>>One major issue for me is that it is a framework, it has one >>>central class ThreadContext and it is expected that >>>developers will supply their own implementation of a >>>ThreadPolicy. I'm not sure if this is always necessary or if >>>in most cases it functions on its own, it seems to always be >>>necessary. >> > > At this stage it is partially necessary. There is a fairly basic > implementation of the policy I believe. However there is a few "complete" > implementations that can/will be moved back in time (at least when they > stabilize). At which point it will not really be frameworky at all. Makes sense. > However I would recomend holding of moving threadcontext as it is not stable > and still subject to change in future - possibly in backwards incompatible > ways. Threadcontext isn't really part af the framework-containers-components-serverapps Avalon subdivision that's taking place. Since Commons sandbox is exactly for possibly common components that still need to mature, I guess that we could still move it there and keep working on it as if it were here... but with the advantage of having it already in a common place where others can look at it and eventually help making it better. I think that this is the best policy. Basically, take the excalibur left-hand menu. - Containers -> stay in excalibur - Components -> new cornerstone - Resource Managers -> dunno - Testing and Analysis -> dunno - Utilities -> *all* to commons (except the ones improperly here) This is how I see the new excalibur, what do you think? What should we do about Resource Managers? Make them just new-cornerstone components? Testing and Analysis can just remain part of excalibur. Comments? -- Nicola Ken Barozzi nicolaken@apache.org - verba volant, scripta manent - (discussions get forgotten, just code remains) --------------------------------------------------------------------- -- To unsubscribe, e-mail: For additional commands, e-mail: