On Sat, 2006-02-25 at 17:56 +0000, robert burrell donkin wrote:
> it should be much more reliable to allow per TCCL configuration whilst
> loading implementations from the class classloader. IMHO we've encourage
> too much use of automagic configuration. suggesting that users use
> various arrangements of jars to achieve configurations has proved a poor
> plan. limited automagic configuration to just the class classloader
> would be a major simplification.
I don't see how that could work.
If the underlying log implementation uses the TCCL to locate config
info, then things are fairly simple; the user just disables TCCL
functionality for JCL and lets the underlying logging system do its
thing.
But if the underlying log implementation is not TCCL-aware, and uses the
ClassLoader which loaded the logging library to locate its config info,
then JCL *must* load that implementation via the TCCL in order to get
the desired behaviour when JCL is deployed in a "shared" location.
And if we want to allow a webapp to redirect logging from classes it
calls which are in a "shared" classpath into a logging lib that is *not*
in the classpath (eg when webapp deploys log4j, container has something
else) then again the TCCL must be used.
I do agree that "magic" configuration wasn't a good idea in hindsight.
Perhaps a commons-logging.properties file should be mandatory?
>
> i've also been toying with the idea of a Log implementation that
> discovers which implementation to use based on the calling TCCL. when
> debug is called, the Log implementation would be looked up. this would
> allow a library to share a static implementation. of course the
> configuration for each TCCL would have to be stored centrally.
You mean this?
public boolean isDebugEnabled() {
// get tccl
// build a (tccl, categoryname) pair
// do a hashmap lookup using the above pair to get the real Logger
// return realLogger.isDebugEnabled()
}
That will work under all circumstances, but the crippled performance
would seem to make this an unworkable solution IMO.
Cheers,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
