axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From rsi...@us.ibm.com
Subject RE: cvs commit: xml-axis/java/test/wsdl/multithread MultithreadTe stCase.java
Date Wed, 03 Jul 2002 14:29:48 GMT
Glen/Costin

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            rsitze@us.ibm.com
CORBA Interoperability & WebServices
IBM WebSphere Development


                                                                                         
                                             
                      costinm@covalent                                                   
                                             
                      .net                     To:      axis-dev@xml.apache.org          
                                             
                                               cc:                                       
                                             
                      07/02/2002 05:07         Subject: RE: cvs commit: xml-axis/java/test/wsdl/multithread
MultithreadTe stCase.java  
                      PM                                                                 
                                             
                      Please respond                                                     
                                             
                      to axis-dev                                                        
                                             
                                                                                         
                                             
                                                                                         
                                             




On Tue, 2 Jul 2002 rsitze@us.ibm.com 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



Mime
View raw message