RE: cvs commit: xml-axis/java/test/wsdl/multithread MultithreadTe stCase.java

[Glen Daniels]

OK, here's my reasoning.

 

The Jakarta common logging API exists *precisely* to define a flexible and simple API to support multiple logging systems.  If you have a problem with the way LogFactory works, or think it's not extensible enough, then that is something to bring up with the commons logging guys - I am sure they'd want to hear about ways the package can be improved.  I don't think building our own shim in front of the factory does any good either for us or for them.  One of the benefits to a standard API is that people get comfortable with it, and don't need to learn Yet Another Factory API for Loggers.

 

My point here is that if you're going this far, why not just replace the org.apache.commons.logging.Log interface with org.apache.axis.logging.Log and then we can build our own toolkit to do exactly the same thing?  I do not want to go there, and I think your change is already going too far.

 

I'm willing to keep discussing this, but for now, my -1 stands.

 

--Glen

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, July 02, 2002 2:37 PM
To: [EMAIL PROTECTED]
Subject: RE: cvs commit: xml-axis/java/test/wsdl/multithread MultithreadTe stCase.java

Glen, I understand BUT.. Calling LogFactory.getLog
- 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]>

Glen Daniels <[EMAIL PROTECTED]> 07/02/2002 01:16 PM Please respond to axis-dev

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
>
>
>