axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [commons-logging & axis] Factories & logical groupings
Date Thu, 25 Jul 2002 18:30:01 GMT
[this is relevant to axis, just not apparent at the onset].

So, the question is:  how do you *use* commons-logging, and other 
components in an application server (internal logging) AND still let users 
package/use these components in their applications (they want control of 
the logging)?

commons-logging LogFactory currently caches discovered Factories by 
ClassLoader.  Even if it didn't, the way the J2EE classloaders work today 
the version packaged with the appserver will be found before the user's... 
this includes, of cource, files.  So there is 
no way for the user to override the factory or properties.

Proposed solution:

A 'groupContext' identifier, to be used to:

a.  Qualify the ClassLoader in the cache, so factory instances would be 
unique to ClassLoader/groupContext.
b.  Qualify property file names:, 
with fall-back to
c.  [not so sure about this one...] Qualify property names:, with fallback to 
org.apache.commons.logging.LogFactory.  [would allow override of system 
property for group]

Then, the application server can obtain a LogFactory unique to it's 
'appServer' group, leaving applications *hosted* by the server free to use 
the default (no group) or to define their own group.  To make this work, 
middle-ware components that use LogFactory, such as Axis, would need to be 
able to accept a groupContext setting and propogate to it's use of the 
LogFactory (and other commons-components that are so-enabled).  Axis would 
of course benefit from this, by being able to use the groupContext 
qualifer on it's (future) file.

** this does not solve the problem of how to package a different version 
of commons-logging, or axis, into a web-app when the web-app-server 
exposes the commons-logging/axis component.  It simply allows the 
component to be *configured* for use by the web-app **

I plan on implementing this mechanism with commons-discovery.  When 
commons-logging is refactored to use commons-discovery, it would inherit 
this function.  Components using Discovery would be able to load classes 
and/or properties files this way.  The key to making this work is 
**ensuring that middleware components respect, use (directly or via 
discovery), and propogate the groupContext properly **.

I would welcome constructive criticism or other working solutions for 


Richard A. Sitze
IBM WebSphere WebServices Development

View raw message