Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 75305 invoked from network); 5 Apr 2002 15:55:35 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 5 Apr 2002 15:55:35 -0000 Received: (qmail 19234 invoked by uid 97); 5 Apr 2002 15:55:34 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 19216 invoked by uid 97); 5 Apr 2002 15:55:34 -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 19174 invoked from network); 5 Apr 2002 15:55:33 -0000 Date: Fri, 05 Apr 2002 10:54:19 -0500 From: "Geir Magnusson Jr." Subject: Re: [logging] Need interface... VOTE In-reply-to: To: Jakarta Commons Developers List Message-id: MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT User-Agent: Microsoft-Entourage/10.0.0.1309 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On 4/5/02 10:17 AM, "costinm@covalent.net" wrote: > On Fri, 5 Apr 2002, Geir Magnusson Jr. wrote: > >>>> o.a.c.genericlog.Log >>>> o.a.c.genericlog.LogUser >>>> o.a.c.genericlog.LogFactory >>> >>> You already have 2 of them ( Log and LogFactory). >> >> In o.a.c.l with some implicit assumptions (which I am trying to dodge...) > > It's quite explicit, and your proposal seem to hava a LogFactory too. The assumptions are *not* explicit - the assumption I am talking about is that you must get the log via a pull from a singleton in o.a.c.l. Again, nothing wrong with that, but wanted to be clear. Yes, I have a LogFactory as well - same interface as o.a.c.l - implementation free - the o.a.c.gl package contains no impl of anything so you can have the gl.jar in your classpath and all is well if you do your own impl... > > BTW, are you going to also propose a o.a.c.genericxmlparser, > o.a.c.genericjdbc, etc ? After all, there are few dozen APIs using the > same pattern with common-logging, do you feel confused when using them > too ? Nope. JDBC doesn't come with an impl, does it? Don't I go and use the mm.sql MySQL driver package throuh which getConnection() will return an object that implements Connection? That's what I am trying to get to here - an implementation free interface spec. Then the basic implementation is commons-logging for the pull crowd, (and maybe push) and anyone who has another idea can do what they want. You guys say you don't want this interface in the Logging package, and then make fun of me when I propose a generic interface package that fully supports the existing and includes it? > >>> What about >>> o.a.c.logmanager.LogUser - define the interface to be implemented by >>> components who want to support setLog() >>> o.a.c.logmanager.LogManager - define interface for setting the >>> properties if a Log, like level, appenders - the minimal stuff that is >>> common to all loggers. >>> (maybe few others ). >> >> That would be cool - but setLog() sets the factory, so you can recover the >> pull model as well w/o giving anything up. > > Fine with me. > > BTW, since static LogFactory.getFactory() uses per ClassLoader data ( so > each application can use a different factory ), we should also add a > static setFactory() method in LogFactory itself. This way you can change > explicitely the default factory for the whole application with a single > call ( instead of calling each compoent's setLog()). I agree with the principle - you just modify your logFactory rather than have to call anything on the components... However, I would think you would want to separate the interfaces, to prevent a *component* from calling setFactory() > > Again, I'm perfectly fine and +1 if you want to set the factory on each > component, maybe you want to use multiple loggers in your app. Right. What I am thinking about here is that you could write a component that does both the static factory pull (catching any exceptions) well as support container push at the same time. Maybe I'm wrong... > > >>> I would be +0 on this ( I think the push and management APIs should be >>> part of c-l itself, not a separate package ). >> >> I do to, but it seems to me that the underlying implementation assumptions >> of o.a.c.l are somewhat at odds with the notion of implementation-free >> generic interface... > > Can you give any arguments for that ( besides 'it seems' ) ? Because if I use o.a.c.l, it's assumed that there exists a singleton somewhere such that LogFactory.getFactory() Will work. That SEEMS like a huge assumption and requires an implementation to be part of o.a.c.l I want to just define the interfaces separately in o.a.c.gl that o.a.c.l builds upon with the current implementation strategy. People could still use o.a.c.l as is w/o even knowing about o.a.c.gl, o.a.c.gl could be used w/o knowing about o.a.c.l, and things that support o.a.c.gl could also be used in a o.a.c.l environment, as the Logs and Factorys are compatible. (I believe the above - will need to try out with actual code... :) > > Is there anything in Log that is not implementation-free ? Is there any > requirement to use Log with a named-based pull system or force ? > ( or even to force it's use with LogFactory ). No - the problem as I see it, and I maybe hugely mistaken, is in the expectation - that if I am in an o.a.c.l environment, I can assume that I can do a pull to get the Log or factory. This makes me worry that if I have a system that claims that logging is done via o.a.c.l, then I have to provide the ability to pull. With the idea of o.a.c.gl, there are no implementation expectations on the part of the component, or requirements placed on the containing environment. > > LogFactory is a helper for people who want a one-line init code > for logging. It does some magic to guess what logger is in the classpath, > and that's it. I wouldn't use anything more complex - if using > commons-logging requires implementing an interface or creating setters, > then I prefer to use println. > Like I have been trying to say - there are no implementation requirements on the part of the component. The component can *choose* to implement o.a.c.gl.LogUser, or not. Keeping it out of o.a.c.l means that the problem goes away for the o.a.c.l mavens. If you want to pull all the time, use o.a.c.l. Don't even worry about o.a.c.gl If you want to pull in some other environment, you can do that, as it is assumed that the component and environment have an agreed-upon scheme, and that the thing the component logs to looks like o.a.c.gl.Log. I know you can do this now in o.a.c.l, but there is this trend for o.a.c.l components to *expect* the LogFactory pull model, as the impl is in the o.a.c.l jar. If you have some other implementation idea or lifecycle, use o.a.c.gl -- Geir Magnusson Jr. geirm@optonline.net System and Software Consulting The obvious solutions are challenging -- To unsubscribe, e-mail: For additional commands, e-mail: