Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 99528 invoked from network); 2 Feb 2002 18:46:39 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 2 Feb 2002 18:46:39 -0000 Received: (qmail 23436 invoked by uid 97); 2 Feb 2002 18:46:40 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 23410 invoked by uid 97); 2 Feb 2002 18:46:39 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 23399 invoked from network); 2 Feb 2002 18:46:39 -0000 Date: Sat, 2 Feb 2002 08:33:46 -0800 (PST) From: X-X-Sender: To: Jakarta Commons Developers List Subject: Problems with commons-logging In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Here's a list of problems I see in the current logging API. Given that a lot of packages will eventually depend and use this API, I believe at least the first issues should be resolved before a release. - security: getLogNames() and getInstance() are evil and unacceptable. Both log4j and logkit have solutions that allow safe use in a container environment, i.e. support of isolation for the users of the API ( one app using the package can't mess with another app's logging ). I'm -1 on releasing with this whole in it. - static methods in LogSource. I suppose LogSource is a sort of factory - the pattern used here is completely unnatural ( or at least different from most APIs in use ). - I would prefer Log to be an abstract class or even to be a normal class, with the minimal logger - and have LogSource return a particular impl. If static methods are used, it's cleaner to put them in Log, and let the LogSource ( I would rename it LogManager ) be used behind the scene. I.e. Log log=Log.getLog( name ); and getLog() will find a LogManager, etc. - It's missing a log() method that takes a level parameter. Having 5 fixed levels is fine for most apps, but not extensible enough. Most loggers provide such a thing. - also in the 'container use' case, given that the Logger will probably be used by many components it's likely it'll end up at top level loader. It would be important for different apps to use different logger adapters if they want to - the current solution allow only one. - Given that it is a facade, it would need some way to pass at least config info to the underlying logger ( at least setProperty like ). Some logger may not need any, but if they do it'll require using internal APIs. - I don't like the idea of constructors with a param. All other APIs use a no-param constructor. You can easily call a setter if you need to. - pluggable mechanism for finding the impl. Right now everything is hardcoded. Reading a properties from CLASSPATH or a similar mechanism is needed. ( jaxp style preferable - i.e. java services manifest ) - Separation of interface and impl - the 2 classes that 'matter' are Log and LogSource, everything else should be in a different package. It'll get messy long term, and it's harder to read. - I would prefer for the base impl to be JDK1.1 compatible. There is no valid reason to exclude JDK1.1 usage - Hashtable can be used without any problem, there is nothing performance critical here. - makeNewLogInstance comment and impl are completely of sync. - no support for i18n-style messages. Probably not a big deal for the first release, but it would be nice to think about it ( I know log4j can do that, I assume other as well ). Costin -- To unsubscribe, e-mail: For additional commands, e-mail: