I understand that the cost is LOW (we are using 'static Log' now). I also understand that I've introduced one more level of abstraction.
I understood Axis to be both a frame work and a SOAP solution. My focus is the framework, and integrating that framework into/with other products through pluggable/swappable components. Particular when those components are incidental (i.e. logging) to the intended function of the framework.
When I'm working on a project, it's always my goal to minimize individual modules/components/classes direct exposure to external dependencies EVEN when the stated charter for such a dependency is as ideal as commons-logging. Glen, I ALMOST proposed that we have an 'interface org.apache.axis.Log extends org.apache.commons.logger.Log { }' for just that reason (and I would have presented that to the group.. but I'm not). By hiding LogFactory from every piece of Axis code EXCEPT the one point, I've cut the exposure to external components/interfaces. If we were to take that next step (axis.Log), we'd eliminate the direct dependency on an external component completely to all but the one class (AxisInternalServices). Regardless, I'm not there yet, so this discussion is academic.
Back to LogFactory. The point of commons logging is not to use of LogFactory, the point is 'Log'. LogFactory was incidental to Log: it's a tool that some would argue (and have) is an anomoly that doesn't properly belong. Moving it out of view DOES make sense.
If/when we push the 'discovery' service (costin, you have no recent comments on that - so are we ready to push it out of the sandbox?) out and integrate LogFactory with that, then our hashtable lookup will be replaced with two looks ups (one by service spi [LogFactory], the second by classloader). Still relatively small overhead, I agree BUT unnecessary. LogFactory provides the 'getFactory' method AND makes it public for EXACTLY the use I've put it to in AxisInternalServices. I'm not breaking the model at all.
I guess I'm trying to work both ends (and middle) of a bridge: axis, logging, and discovery. I don't want my efforts on the last two to have detremental impact on axis (no matter how slight).
<ras>
*******************************************
Richard A. Sitze [EMAIL PROTECTED]
CORBA Interoperability & WebServices
IBM WebSphere Development
[EMAIL PROTECTED] | 
07/02/2002 05:07 PM |  To: [EMAIL PROTECTED] cc: Subject: RE: cvs commit: xml-axis/java/test/wsdl/multithread MultithreadTe stCase.java |
On Tue, 2 Jul 2002 [EMAIL PROTECTED] wrote:
> Glen, I understand BUT.. Calling LogFactory.getLog
> - forces a hashtable lookup on every call to obtain the correct LogFactory
> implementation (key is classloader)...
That's why you would call LogFactory.getLog() only once, at init time.
Most projects are using a static field - and the cost is minimal.
> - doesn't guarentee that the LogFactory implementation found is the same
> one used by the rest of Axis (context class loaders, etc)
That may only happen if you have multiple logger implementations and
a strange configuration.
> 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.
Well, that may conflict with what we are trying to do in tomcat - i.e.
allow central configuration ( probably JMX based ) of the loggers.
Also creating a hook and configuration for axis logging factory may
conflict with the container hooks and configurations.
There are ongoing discussions with Ceki and on tomcat-dev on how to
deal with the logging and log configuration.
Costin
