On Thu, 2004-05-13 at 01:32, Inger, Matthew wrote: > The only real issue i have with commons-logging is the > hardcoded list of loggers that are available, and having > to include the adapters for those loggers in our programs > no matter what. It would be nice to have a service provider > (read discovery mechanism) to figure out what log package > adapters were available. In that way, each adapter implementation > could be put in it's own jar, as well as having a strictly api/factory > jar.
Hi Matthew, I don't understand what the issue is.. Commons-logging does implement the standard "service provider" mechanism: put a FooLogFactory and FooLog implementation in your classpath, then in META-INF/services, include a file named "org.apache.commons.logging.LogFactory", with its first line being: com.acme.FooLogFactory And there are 2 other mechanisms for dynamically configuring the logging adaptor used by commons-logging. There isn't anything "hard-coded" about that as far as I can see... Commons-logging does bundle adaptors for avalon LogKit and log4j. But if you don't use them, then what is the problem? And jar "commons-logging-api" leaves these out, if you really wish. It does include NoOpLog and SimpleLog for obvious reasons. It also includes JDK1.4 logger; I'm not sure why, but I can't see any problem with this either. I don't think I would be in favour of commons-logging distributing separate jars with the logkit and log4j adaptors in, because these jars would be *ridiculously* small. Have I missed something? Regards, Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
