Return-Path: Delivered-To: apmail-jakarta-avalon-apps-dev-archive@apache.org Received: (qmail 30470 invoked from network); 12 Mar 2002 14:37:29 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 12 Mar 2002 14:37:29 -0000 Received: (qmail 13714 invoked by uid 97); 12 Mar 2002 14:35:06 -0000 Delivered-To: qmlist-jakarta-archive-avalon-apps-dev@jakarta.apache.org Received: (qmail 13685 invoked by uid 97); 12 Mar 2002 14:35:05 -0000 Mailing-List: contact avalon-apps-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Avalon Applications Developers List" Reply-To: "Avalon Applications Developers List" Delivered-To: mailing list avalon-apps-dev@jakarta.apache.org Received: (qmail 13640 invoked from network); 12 Mar 2002 14:35:05 -0000 Message-ID: <3C8E1126.8070306@yahoo.com> Date: Tue, 12 Mar 2002 14:31:02 +0000 From: Paul Hammant User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.7) Gecko/20011221 X-Accept-Language: en-us MIME-Version: 1.0 To: Avalon Applications Developers List Subject: Re: Xerces/Xalan and Classloader problem References: <3C8DEC30.6A381F27@denic.de> <3C8DF692.8080304@yahoo.com> <3C8DFA5D.54C8BF78@denic.de> <3C8E04E9.2050805@yahoo.com> <3C8E0565.886E90B6@denic.de> 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 Ulrich, >>Dunno. Reason I mention it is that some teams make an assumption (when >>instantiating a classloader) that the parent is the primordial. The >>Catalina team is (or was) one of them! >> > >What do you mean by primordial? Is that like the top classloader? What >can go wrong, when I assume a classloader to be the top classloader, >when in reality it isn't? > It is a comon mitake. If you are making a reusable thing that does classlading, you should always specify the parent CL. If you don't it will just fail to find depended on classes when in use when some person tries to reuse the thing "up a tree" of classloaders (like Phoenix). It is porbbaly not your problem as it would not be an intermittent issue. >Do you have any idea where in the Phoenix sources I should look for >classloader/startup code? > On reflection I do not think classloading is your issue. >Sorry for asking so many dumb questions, but I have to get as much >information as possible, this issue is currently impossible to debug :) > No thing is impossible dude. You are going to have to temporarily fork the latest phoenix and put old fashioned debug messages in. It is a good way of understanding phoenix. - Paul -- To unsubscribe, e-mail: For additional commands, e-mail: