Return-Path: 
 <commons-dev-return-70853-apmail-jakarta-commons-dev-archive=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-commons-dev-archive@www.apache.org
Received: (qmail 96733 invoked from network); 4 May 2005 17:41:25 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 4 May 2005 17:41:25 -0000
Received: (qmail 93352 invoked by uid 500); 4 May 2005 17:41:44 -0000
Delivered-To: apmail-jakarta-commons-dev-archive@jakarta.apache.org
Received: (qmail 93141 invoked by uid 500); 4 May 2005 17:41:35 -0000
Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:commons-dev-unsubscribe@jakarta.apache.org>
List-Subscribe: <mailto:commons-dev-subscribe@jakarta.apache.org>
List-Help: <mailto:commons-dev-help@jakarta.apache.org>
List-Post: <mailto:commons-dev@jakarta.apache.org>
List-Id: "Jakarta Commons Developers List" <commons-dev.jakarta.apache.org>
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Delivered-To: mailing list commons-dev@jakarta.apache.org
Received: (qmail 93093 invoked by uid 99); 4 May 2005 17:41:33 -0000
X-ASF-Spam-Status: No, hits=0.1 required=10.0
	tests=FORGED_RCVD_HELO
X-Spam-Check-By: apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Received: from torino.qos.ch (HELO mail.qos.ch) (212.74.184.209)
  by apache.org (qpsmtpd/0.28) with ESMTP; Wed, 04 May 2005 10:41:33 -0700
Received: from kal.qos.ch (kal [192.168.1.3])
	by mail.qos.ch (Postfix) with ESMTP id 67103D5888;
	Wed,  4 May 2005 19:39:13 +0200 (CEST)
Message-Id: <6.0.3.0.0.20050504193500.01f52ca0@torino>
X-Sender: blocked@torino (Unverified)
X-Mailer: QUALCOMM Windows Eudora Version 6.0.3.0
Date: Wed, 04 May 2005 19:39:15 +0200
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>,
	Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
From: Ceki =?iso-8859-1?Q?G=FClc=FC?= <blocked@qos.ch>
Subject: Re: [logging] tech.xml - child-first classloading not
  considered harmful
In-Reply-To: <1115228277.4708.41.camel@knossos.elmet>
References: <20050503145849.25209.qmail@web60323.mail.yahoo.com>
 <1115228277.4708.41.camel@knossos.elmet>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Virus-Checked: Checked
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N


Isn't the term child-first a misnomer? A class loader can't be a child of=20
itself? Can it?

IMO, the term "parent-last" is an improvement over child-first,=20
"parent-second" being even a little more precise.


At 19:37 5/4/2005, robert burrell donkin wrote:
>On Tue, 2005-05-03 at 07:58 -0700, Mike Colbert wrote:
>
><snip>
>
> > As an aside, isn't "child-first" really a misnomer and it's more like
> > "parent-last"?  Assuming the parent is at the top of the hierarchy,=20
> child-first
> > implies (to me), that the heirarchy is walked downwardly from the=20
> parent, not
> > upwardly from the bottom.
>
>oh, if only it were all so simple :)
>
>real life classloader hierarchies can (and regularly do) mix the two
>types. so, it's really only possible to talk about the behaviour of a
>single classloader.
>
>- robert

--=20
Ceki G=FClc=FC

   The complete log4j manual: http://www.qos.ch/log4j/



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org