On Sun, 2006-02-26 at 17:26 +1300, Simon Kitching wrote:
> 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 was thinking along the lines of mandatory for actively choosing a
logging system. JCL could still make a reasonable guess but using a
properties file would become the primary recommended mechanism for
configuration.
> > 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.
i've been wondering about how big the performance impact would actually
be. it's a way of achieving true isolation for those that really need it
at a price. might encourage users to think about the trade-offs involved
a bit more than they do now.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
