Paul Hammant wrote, On 09/02/2003 13.40:
Nicola,
>>Paul Hammant
My point was that A-F 'uses commons-logging' is a meme that will only add to cunfusion.
I tend to agree.
Craig explained to me this:Well for a start, a central log factory for all components running in a container is not instance centric. It may not even be application centric. The best we could hope for is some -D parameter on boot to set a custom factory for commons-logging and the bundling of the commons logging jar (and our impl of their abstract factory) in each conceptual application. i.e. multiple copies of the same jars in a classloader tree. Only then can some hack/thunk through to Avalon's logging happen.I did much experimentation some months ago. It is not so easy.3) Every Avalon container registers it's own LogFactory as a top-level LogFactory, so that it intercepts *all* logging calls and can deal with them in a centralized way, somewhat inverting the control.Why?
"
That's a really important question, especially in things like a servlet container. The current implementation of LogFactory.getFactory() configures a LogFactory instance per class loader. It also has support for using the thread context class loader to make this determination, instead of the class loader used to load commons-logging itself. This
makes things work nicely in an environment like Tomcat, where you can have the API classes (commons-logging-api.jar) in a shared parent class loader, yet allow each app (loaded by a separate child class loader) configure its own LogFactory and logging configuration.
"
and
"
Do you mean "how does a webapp configure it's own usage of
commons-logging"? That's typically done by supplying a
commons-logging.properties in /WEB-INF/classes, or in a JAR file inside
/WEB-INF/lib (either of which makes it visible to the webapp class
loader). The discovery mechanisms in LogFactory are very carefully
crafted to make this work in a way that allows for independent
configuration at the per-class-loader level.
"
> It is all very dirty though.
strict IOC is definatley *much* cleaner. That's not in question anyhow.
I asked that, and James S. seemed positive, while others not so keen. Hmmm...If weThey pointed out that CL can easily be used with IOC. Just don't use the static accessor and use a setLogger method.
can eradicate the static nature to Commons-Logging (and most importantly its usages in Commons) we have a chance of making it work. C-L was not designed at all with IoC in mind...
If they can change usage patterns then great.
I think that the best deal we could cut is to add a setLogger() method to every class that uses it, and make it default to the static accessor in case it's not set.
The fact is that it's really not feasable to pass loggers in an IOC way everywhere in bean code. I tried it with POI, and it was a mess.With the greatest of respect, POI should not use any logging. It is a reusable comp. It is an application coders choice to use logging or not.
You mean that this "logging" is just for the app writer? I agree.
Ok, it's called "logging" but it's more "tracing".The fact is not that static accessors solve a need, a *real* need, that is access to a logger for fine-grained components with big hierarchies.
If we solve the need in another way, static accessors may not be needed.
Logging is a want not a need in most cases :-)
Oversimlpifying, Logging should be that thing that records what happens in an app at runtime in a *deployed* environment.
Tracing does it at debug-time. No user of POI would ever care about what POI "logs".
Only the "service" part of POI should log, and that's not many classes, so IOC can be used nicely.
That's why I'm interested in your approach :-)
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
