- forces a hashtable lookup on every call to obtain the correct LogFactory implementation (key is classloader)...
- doesn't guarentee that the LogFactory implementation found is the same one used by the rest of Axis (context class loaders, etc)
By getting calling and caching LogFactory.getFactory(),
- we go directly the the correct instance every time.
- avoid differences in class loader etc.
- Provide a single hook where (if needed) the log factory could be overriden by axis, rather than depending upon the logging configuration to figure out the right one...
I've got a side agenda with this in that in the (near future?) I can override the logger's configuration file and have it use one provided by axis, possibly the same configuration properties file that axis will use in the near future.
I've got to run for the afternoon, but I may be checking mail this evening..
<ras>
*******************************************
Richard A. Sitze [EMAIL PROTECTED]
CORBA Interoperability & WebServices
IBM WebSphere Development
Glen Daniels <[EMAIL PROTECTED]> | 
07/02/2002 01:16 PM |  To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> cc: Subject: RE: cvs commit: xml-axis/java/test/wsdl/multithread MultithreadTe stCase.java |
Rick:
I'm sorry, but I'm still -1 on getLog(). I think it simply obfuscates what is already a clean and extensible interface.
I'm fine with a generic way of getting properties from "the universe", but I see no need for getLog().
--Glen
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, July 02, 2002 2:08 PM
> To: [EMAIL PROTECTED]
> Subject: cvs commit: xml-axis/java/test/wsdl/multithread
> MultithreadTestCase.java
>
>
>
