Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Message-ID: <3FA6DAE7.5010202@apache.org>
Date: Mon, 03 Nov 2003 23:47:03 +0100
From: Remy Maucherat <remm@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.5) Gecko/20031007
MIME-Version: 1.0
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: commons-logging & classloading (continued)
References: <3E6022EC-0D80-11D8-8FDB-003065DC754C@blueyonder.co.uk>
 <3FA65308.1030903@umich.edu> <3FA66CA1.5010808@umich.edu>
In-Reply-To: <3FA66CA1.5010808@umich.edu>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Will Jaynes wrote:
> Well, I submitted this as a bug and included a patch. But Remy 
> immediately marked it as RESOLVED/WONTFIX. He doesn't really address my 
> suggestion other than to say that c-l "if used properly ... is well 
> thought out, and works perfectly well" I would never suggest that c-l is 
> not well thought out. However, I don't think that all the problems we 
> see involving c-l classloading can be attributed to us not using c-l 
> "properly". It may work perfectly well with Tomcat5, but that doesn't 
> mean there aren't improvements that can be made. Or even accomodations 
> that could be made to other containers than Tomcat5.
> 
> Could someone please explain why the suggestion to load the Log 
> interface with the loadClass() method is not acceptable.

- The core Log classes should be loaded once from one place (= 
(basically) they should be in the system classloader)
- the log implementations (ex: the log4j implementation) should reside 
in the same classloader as the logger; ideally, the logger ships with 
wrapper classes for commons-logging

This is the most efficient design, and fairly easy to understand. 
Coincidentally, this is the design that commons-logging implements, and 
it is good for a complex container environment.

Remy


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